Re: auth_rewrite authenticate.c user_auth_hash_pointer usage

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Sunday, January 14, 2001 11:24 AM
Subject: Re: auth_rewrite authenticate.c user_auth_hash_pointer usage

> Robert Collins wrote:
> >
> > Right. The proxy_auth dlink is obsolete -
> > I thought I'd #ifdef GLOBALPROXYHEADERCACHE but obviosuly I haven't.
>
> The same structure is used in auth_ntlm.c.

The structure is yes - the link back from auth_user_t to it isn't. (ntlm uses a scheme specific list back.

> > The point was to allow multiple references back to a single
> > structure that need to be cleaned all at the same time.
>
> Like what you do in ntlm_auth.c.

Yes

> > Aliases: a single scheme's auth_user->scheme structure can
> > potentially have aliases - multiple auth_user structures pointing
> > at it (and return different usernames). It's not supported by any
> > of the current modules, and may need a little more API tweaking to
> > work fully. As far as memory usage goes - I was going off the fact
> > that 10,000 users, will only use ~2M of memory.
>
> I don't se how that belongs in the username hash for auth_user. Feels
> more like the job of a list inside the scheme specific data to keep
> track of which user_auth that references this scheme structure.
>
> If you were talking about username aliases where one auth_user could
> have many names then it makes sense, but as long as "one username ==
> one auth_user" (per scheme) then the indirection above auth_user is only
> confusing.

I am talking about username aliases.

> One more thing I dislike: Today, if you have the same username in more
> than one scheme then you have duplicate entries in the username hash. I
> like to see this unified to one auth_user with multiple scheme specific
> structures attached.

I dislike that too.. but it makes the framework more complex for little gain. A given user is only likely to be in the cache with
different schemes if they are using different software in a short timespan (and ntlm is unlikely to cross over with basic or
digest - so it will be very rare to have that occur). I don't think it's going to be that common.

To do that I think several things should happen first: some of the auth_user items are used in each scheme. The layout of data needs
to be tuned so no auth_user_t data is altered by schemes. The AUTH_DIGEST/AUTH_BASIC/AUTH_NTLM defines need to be optimised out for
the module Id or a pointer to the scheme_list entry. Then a couple of support functions at the framework level to allow schemes to
say "I have user joe" and get linked in. Then some very very very careful testing to make sure we never cross over from one scheme
to another while handling a request.

Rob
Received on Sat Jan 13 2001 - 17:31:58 MST