Re: [squid-users] login screen

Squid ACLs cannot currently be updated 'on-the-fly'. Squid can use an
external ACL file, which is included on a restart or reconfigure.

I think you're probably assuming a somewhat simpler solution than what
is required...In order to handle realtime authentication, you'll need a
redirector that understands the backend auth database, and knows how to
expire authenticated IPs after a certain time of inactivity. A simple
user list will not work for at least two reasons: First, you can't
handle expiry from the CGI, and second reconfiguring Squid every time a
user IP is added or subtracted from the list will not scale very
efficiently. It will probably be ok for 5-10 simultaneous users. More
will likely cause troubles.

So, to restate my previous post slightly differently, you need two
things (note in the below comments, database has nothing to do with
whatever user database or password file is being authenticated
against--they are separate things...this database is a "Currently logged
in user IPs and possibly some state information to aid in expiring the
user"):

1. A CGI script that authenticates users. This accepts a user/password,
and enters that clients IP into the database. The CGI is done. It
can't do anything else. (You could run an expiry cron job, which
expires users every X hours or minutes, but number 2 is a more efficient
and effective way to do it. An expiry based on the time of entry into
the authenticated users list is kind of braindamaged and would be a
nuisance for frequent users, and allow abuse of accounts that haven't
timed out quickly enough.)

2. A redirector that shares the database with the CGI script. Everytime
a request comes in it checks to see if the IP is authenticated, if it
is, it directs to the requested URL, otherwise the user gets the login
CGI. Expiry /can/ be handled by the redirector by inserting a
last-request timestamp everytime the user makes a request. If the next
request comes X hours or minutes from the last request, the current IP
is expired and a new login is forced.

The term 'database' here is used in its simplest sense. If Postgres is
the easiest for you, that's what you should use...But any old database
would work, including plain ol' textfiles, BerkeleyDB, DBM, SQLite, etc.

I believe part of what you're missing is that you /can't use user ACLs/
with this method of authentication. Squid /never/ knows the username
when authenticating this way, and thus cannot filter based on username.
  You have to handle that in your redirector (which has to have the
smarts to handle whatever type of ACL you want it to handle). In other
words, you aren't authenticating to Squid anymore...you are
authenticating to a redirector, and Squid is simply asking the
redirector what to send the user for each request.

Ryan Hairyes wrote:
> What about this:
>
> setup a website for user login and password. Have it auth. to the database.
> If the user's username and password are correct then have it insert the IP
> address in to a database (like postgres). Then setup acl's for each ip address
> allow them in. Or something to that effect. This plan obviously is not well
> thought out, but I was looking for a starting point. I will continue to think
> on this but any more advice you can give me will be greatly appreciated.
>
>
>
> Quoting Joe Cooper <joe@swelltech.com>:
>
>
>>Not without custom programming.
>>
>>The key part of this is that your CGI must update the database in
>>realtime, while the redirector must consult the database to check
>>whether the user has logged in (and if not, they should be redirected to
>>the login page).
>>
>>Another slightly difficult part of the equation is timeouts--i.e. how
>>long between accesses does the IP go out of the list of authenticated
>>users? And how does it get updated? Most likely the redirector also
>>needs to have write access to the database in order to expire users who
>>haven't accessed in X minutes (a simple "Last-accessed" field in the
>>database can handle this, but maybe not in the most efficient way, since
>>it has to be updated on every request).
>>
>>SquidGuard does use a backend database, but it has no notion of
>>timeouts, nor the ability to modify the backend database.
>>
>>It would probably be easiest to start from scratch, rather than
>>modifying SquidGuard, which was never designed with the plan of
>>replacing authentication. Then again, if you also need the
>>functionality of SquidGuard, you'll likely want to start there and build
>>on it.
>>
>>Ryan Hairyes wrote:
>>
>>>>b) Writing a redirector or external_acl helper to Squid that uses this
>>>>database to authorize the request.
>>>>
>>>
>>>would something like squidGuard work for this????
>>
>>--
>>Joe Cooper <joe@swelltech.com>
>>Web caching appliances and support.
>>http://www.swelltech.com
>>
>
>
>

-- 
Joe Cooper <joe@swelltech.com>
Web caching appliances and support.
http://www.swelltech.com