sön 2011-12-18 klockan 01:46 +1300 skrev Amos Jeffries:
> >> This will not process auth headers if presented but not yet
> >> authenticated. But it will allow IDENT and external ACL out-of-band
> >> authorization usernames to be sent to the helper.
> > It should probably process auth headers if presented, but not challenge
> > for authentication if no headers at all are presented.
>
> Trouble is, do we do it for all schemes? (meaning adding username
> decode inline for all of them)
> or just the Basic one where username decode is already in the main code?
I do not propose adding any user name decode of any form. Just a flag in
the acl directive (or perhaps http_access) controlling if we should
challenge for new credentials or not when processing this acl.
Processing of existing auth headers (including sending intermediary
challenges) should continue as usual. This flag should only block
a) Request of new credentials when none is presented
b) Request of different credentials when denied access
> NTLM and Negotiate auth have no username in current Squid until after
> teh full challenge handshake is performed.
Yes, and the confusion in communication here is in what we read into the
flag I think.
The proposed flag should not block auth processing as such, or even
intermediary challenges in pending processing. Only request of new
credentials (no auth header at all sent by client on a non-authenticated
connection) or rechallenge on http_access deny.
Regards
Henrik
Received on Sun Dec 18 2011 - 19:39:06 MST
This archive was generated by hypermail 2.2.0 : Mon Dec 19 2011 - 12:00:09 MST