Re: [squid-users] advisory message before browsing
On Wed, 3 Nov 2004, Rolf wrote: All users will be subject to basic auth upon first trying a url. Ok. trivial. Having been authenticated they get to the policy page, but upon return from the policy page, I can't see how to know they've been there and not to redirect them again. As I said your redirector and the policy page needs to be sharign a common database of which users have accepted the policy. This is indeed your excellent policy accepted database idea Yes. but how can I implement it? By selecting the type of database you use, then write a redirector and a CGI capable of accessing this database to exchange the information about the status of the user. Can I do so with ACLs and redirector_access? Via an external acl helper yes. Just remember to set the negative ttl to 0. It sounds like it needs some database arrangement that is populated by the script that runs the policy page. And de-populated by some other scheduled task that removes old entries. A simpler design is to simply store a timestamp in the database indicating when the user last accepted the policy. But, how does squid see these entries? By your redirector or acl helper querying the same database as the policy page script. Regards Henrik
Re: [squid-users] advisory message before browsing
On Tue, 2 Nov 2004, Rolf wrote: I can get that a redirector would be handy - squid sends the requested url to the redirector (any url or only unapproved ones for eg) which is then rewritten to the advisory page. This would display the advice page in the same browser window. But then how does one construct the mechanism to continue to the requested url? This is possible by a) Have the redirector and your policy page share a common database on users who have accepted the policy. b) Have the redirector send the original URL as a query argument to your policy page, allowing the policy page to redirect back to the original URL when the policy is accepted and this user has been added to the policy accepted database. Seems that the url for the advice page could be comprised of javascript to cause a new window to appear - is it as simple as once such a window is dismissed the requested url would get loaded? Trivial JavaScript coding... opener.location = the_original_url; window.close(); assuming you have already figured out how to get the original URL. How you present this thing or get back to the original URL after the redirection is all about HTML/JavaScript, nothing really relevant to the proxy. Further how is this accomplished so that the warning advice only appears upon first using the browser (time limited or what)? If you do this in the proxy time is about the only variable you have. There is other approaches solving this outside of the proxy. It is also possible solving it at the client by using a clever proxy-pac script (assuming you have control over the clients). Regards Henrik
Re: [squid-users] advisory message before browsing
Hello Thanks very much. To follow up... I can get that a redirector would be handy - squid sends the requested url to the redirector (any url or only unapproved ones for eg) which is then rewritten to the advisory page. This would display the advice page in the same browser window. But then how does one construct the mechanism to continue to the requested url? b) Have the redirector send the original URL as a query argument to your policy page, allowing the policy page to redirect back to the original URL when the policy is accepted and this user has been added to the policy accepted database. Have done this and it works beautifully. Used a short javascript that accepted ?url=www.orig.url as an argument to the policy page url. Was quite simple. Further how is this accomplished so that the warning advice only appears upon first using the browser (time limited or what)? If you do this in the proxy time is about the only variable you have. I am quite happy to have time as the measure to determine when the policy page re-appears. Though I am a bit stuck here. Is it possible to adapt the proxy auth mechanism I am wondering. All users will be subject to basic auth upon first trying a url. Having been authenticated they get to the policy page, but upon return from the policy page, I can't see how to know they've been there and not to redirect them again. This is indeed your excellent policy accepted database idea, but how can I implement it? Can I do so with ACLs and redirector_access? It sounds like it needs some database arrangement that is populated by the script that runs the policy page. And de-populated by some other scheduled task that removes old entries. BUt, how does squid see these entries? thanks again rolf.
