I have a similar but different requirement in which we need to be able to deny access to a user at any time. Your challenge is going to be that squid caches the users login (as does the browser), and there's no good way to expire a users basic/digest auth credentials in squid - the user must close their browser for the credentials to expire (or perhaps there's some timeout period but I'm not familiar with it as it wouldn't affect my situation). My solution to the problem is to use both an authentication helper paired with a url re-write helper. The authentication helper handles the initial authentication, and then passes some information over to the url redirect helper to indicate that the user did authenticate properly (I just use a simple named pipe for this, and a couple of shell scripts for the helpers). The URL re-write helper gets called for each URL, so it needs to be fast. As such I keep all authenticated users in memory in a hash table. For each URL the url re-write helper checks the authenticated username against its hash table. If the user is blocked it will re-direct the user to a notification page. Here's where our implementations deviate a bit. For me, the notification page provides the user a way to unblock their account and my script polls a webservice for this status and updates appropriately. You will have to figure some way of re-authenticating the user at this point. Keep in mind that you can't easily wipe the basic/digest authentication credentials in squid. Off the top of my head I would suggest providing a web page that handles the re-authentication. That web page would then need to communicate the username back to the authentication helper so subsequent pages succeed. Since you have to do this extra web-based authentication step at the 24h mark, you might even skip the basic/digest authentication and just perform all authentication through this web based approach using only a url-rewrite helper (if the user isn't authenticated it forwards them to the website for authentication). Integration with single sign on might be a thought in your mind at this point too. Anyway, that should be some food for thought for you. Good luck, David -----Original Message----- From: alexus [mailto:alexus@xxxxxxxxx] Sent: Wednesday, August 10, 2011 9:56 AM To: squid-users@xxxxxxxxxxxxxxx Subject: 24h trusted IP I need for squid to do following 1) user authenticate against squid 2) add ip for 24h to a trusted list, so it will not prompt for userid/password until 24h is expired -- http://alexus.org/ ----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3824 - Release Date: 08/09/11
