Re: PATCH: Proxy Authentication patches

Henrik Nordstrom wrote:
>
> Dancer wrote:
>
> > AUTH_WITH_IP:
> > Pass three arguments to the authenticator instead of two. The first is
> > now the source-ip address of the client (second and third are the
> > username and password as usual). Squid's authentication caching is
> > disabled if this is selected.
>
> Please make that as an additional third argument. No fun having
> different autentication modules for different builds of Squid..

Easily done, since it's in an snprintf. Just swap two of the arguments.
I can repost the patch with said modification if you prefer.

>
> > USERDATA_FROM_AUTHENTICATOR:
> > The authenticator is expected to return 'OK __data__' or 'ERR __data__'
> > as an authentication response. If no extra data is returned, the
> > username is left unmodified, otherwise whatever is returned as __data__
> > is used as the username for logging purposes, and is passed to the
> > redirector in the ident field. I can't say for certain if this one works
> > well by itself, since I've only tested it in conjunction with
> > AUTH_WITH_IP, and the modified code structure may introduce some issues
> > with the internal authentication cache.
>
> Not sure I like this to much. I agree that it may be useful, but far
> more useful in a general perspective is to have the authenticator return
> a message to the user telling them why the password was not OK. Also,
> extending the protocol with a additional return code "DENY" might be a
> good idea, to allow the authenticator to return access denial message to
> the client without asking for authentication.
>
> Changing the logged username might be useful in conjunction with this,
> but I would prefer to see it done with some kind of magic key, like
> USER:<whitespace terminated string>.

Hmm. Not a bad thought. What we use it for here:

We have 1400 schools attached to each deployment, and each school has
it's own username namespace. So, AUTH_WITH_IP was an obvious starting
point, as we needed to disable the internal auth-caching, and make sure
the authenticator sees the source address, so we can work out which
school the username is for.

Fine so far. Then we get to filtering, in the redirector...and again, we
need to know which school it is. Source address, right? Yes....but it's
such a _nuisance_ doing two queries in the request sequence just to find
the same piece of information. Additionally when the end-of-day
log-processing occurs, we would be left with the source-ip and the
username, and have to check up a few million lines to determine the
school name again. Time consuming.

So, I added USERDATA_FROM_AUTHENTICATOR so that when I was given the
source-ip, username and password, I could return a new username string
with schoolname/username that would go into the logs, get passed to the
redirector and so on, eliminating all that repeat effort.

Magic key: Hmm. Not a bad thought. I _do_ feel a little jealous about
every extra byte written or parsed (since we've traditionally had some
performance problems with the proxy boxen), but I can see your point.
Are you suggesting the 'USER:' in place of the 'OK', or appended?

D
Received on Tue Jul 29 2003 - 13:15:58 MDT