On 14/09/11 21:36, David Rodman wrote:
HI Amos -
I appreciate the thought -- but here's the rub:
Use the "fake" Basic authenticator to get around the small problem
of needing an auth module configured.
That is the only way to acquire a username and password from the
user, right? So here's the problem:
If the user enters an invalid username and password, the fake
authenticator will still say "OK". That result is cached as valid,
and then when the external acl proc does the actual authentication
and says "ERR", squid will not re-execute the fake authenticator
because it thinks it already has a valid set of credentials from that
one.
I forgot to ask which Squid you are using.
The external ACL using %LOGIN have been made proper side-band
authentication and should trigger re-challenge under the same conditions
as proxy_auth ACL (ie if it it last on the line).
That will not force the browser to do anything though, it may still
re-send the same credentials to the same port. Or it my try repeatedy,
then ask the user (popup) who enters the same ones.
That's why I look up the username/password combination in my
proxy_auth external, so that it will not say "OK" unless there's at
least a good chance that we're going to authenticate this user.
(incidentally - I am using the port to differentiate user groups;
each group has its own authentication database and its own set of
permissions used by the rewriter program.)
The definitely the two-helper setup in Squid is best for all current
releases. Group permissions are too "fuzzy" (I think thats the word
anyway) in relation to users for the strict yes/no results which Squid
helper have to produce for validity. Things get weird real quick when
usernames can be both valid and invalid simultaneously with the same
password.
It's working OK this way but ugly because of the multiple database
lookups and multiple external programs. If I could just pass the
port number to the basic authentication helper, that would do the
trick. The information must be known to Squid at the time it calls
the auth program, because there has to be a live HTTP request
structure, and that's where the port number is stored. But that
structure is not visible to the authenticate routine that actually
invokes the external program.
The details are known yes. But what happens when a second request for
the same username comes in the wrong port within TTL of a request from
the acceptible port? all active requests for the user will become
invalid for ten minutes, with only a new password being able to break
out of that. Trivial DoS vulnerability which users can self-trigger.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.15
Beta testers wanted for 3.2.0.11
