Re: Authentication bug in Squid 2.2S4

Duane Wessels wrote:
>
> On Wed, 18 Aug 1999, Steven Sporen wrote:
>
> > Hi,
> >
> > I picked up a problem with the way the authentication works in squid.
> > Currently when squid uses an authenticator it sends out a line in the form
> > <username> <password>
> >
> > The problem comes in when the user enters a username with a space in it
> > then the second part or surname will be interpreted as the password. The
> > solution is to convert the space in the username to a %20 the way it currently
>
> I know that a number of people wanted to change squid-auth interface.
> Does anyone have a proposal that (hopefully) is flexible enough for
> everyone and won't require changing again in the near future?
>
> Duane W.

Well, the amount of demand for my patches was pretty damn high (I got 30
requests within 3 hours of asking for expressions of interest).
Unfortunately, they're all #ifdef driven. While something is still
nagging at the back of my head about Stephen's 'one-argument-per-line'
protocol to the authenticator, I can't come up with a good reason not to
do it that way to avoid embedded spaces...

Of course, if a space is embedded in a user-name it cocks your logfiles
up, the same way logging an HTTP request with an embedded space does.
That's probably what's been bugging me.

Popular items include sending the source-address down to the
authenticator, and returning arbitrary data to log in the ident field.
(I _did_ eventually manage to hack the authentication cache to cache the
results of IP-based auth, with arbitrarily returned usernames..It turned
out to be fairly straightforward in the end.. Patches will be
forthcoming when I can abstract them out of our production code. I went
a little nuts)

I'm going to express some dubiety about making the auth protocol too
complex though. Right now, it's fast. Yay. Good thing. While I can see a
case for sending space-separated, encoded key=value pairs as an
extensible alternative...I don't like the idea of the performance hit.
There's a whole bunch of other stuff that I wouldn't like to add unless
it was configurable/disableable...and suddenly we get into the whole
mish-mash where we have three or four switchable schemes. Ranging from
current and fast, to new and slow. Bleah.

What's wanted?
* More data to the authenticator. (origin ip at least. Anything else?)
* More data from the authenticator. (set the username for access logging
to any arbitrary string. Neat feature for postprocessing logs..Our help
desk loves this, actually: customername/username(bad-password) in the
logs says it all)
* Sane dealing with spaces. I don't see an alternative to encoding them
(~20) or encode them as a ':' which cannot appear in a proxy-auth
header, I believe...and therefore CANNOT be in a username or password.
Of course, it's got to be encoded rather than multilined or we get into
troubles during log-processing later.

What else is on the wishlists? Let's get it onto the table before we
pick anything.

D
Received on Tue Jul 29 2003 - 13:16:00 MDT