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:ale...@gmail.com] 
Sent: Wednesday, August 10, 2011 9:56 AM
To: squid-users@squid-cache.org
Subject: [squid-users] 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

Reply via email to