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.
