If I had a load balancer mapping many incoming client connections to
fewer backend connections to Squid, would that cause trouble for the
digest authentication logic? In particular, if requests from two
different authenticated users were mapped onto a single connection from
load balancer to Squid (and interleaved?) would that cause trouble?
It seems like there is some cached auth state associated with each
connection, and that the connection multiplexing must be interacting
badly with that. Is there a way to suppress the caching of this auth state?
Henrik Nordstrom wrote:
> tor 2006-08-10 klockan 16:52 -0700 skrev Ben Drees:
>
>
>> Users are complaining that they are challenged to re-enter their
>> credentials too frequently.
>>
>
> Then something is wrong somewhere. They should only need to enter their
> credentials once, just as for basic..
>
>
>> I figured nonce_max_duration would set the "max session time", but the
>> credentials challenges still seem to happen much more frequently.
>>
>
> The nounce duration is not a session timer as such. It's more related to
> replay attacks on the digest protocol.
>
>
>> I notice log entries like these that seem to be correlated with the
>> credentials challenges:
>>
>> #1) authenticateValidateUser: Auth_user '0xb61430' is broken for it's
>> scheme.
>> #2) authenticateValidateUser: Validating Auth_user request '(nil)'.
>>
>> Are these normal sorts of log messages? What does AUTH_BROKEN mean (from
>> the source generating example #1)?
>>
>
> Most likely Squid didn't like something of the Digest message sent by
> the browser.
>
> debug_options ALL,1 29,9
> should give more insight into the Digest processing.
>
> If you enable log_mime_hdrs and repeat the problem with a known password
> then we can look into what the browser sent and if it makes sense or
> not.
>
> Or at mimimum log_mime_hdrs and get the relevant /407 entries. Maybe
> there is something obvious.
>
> Regards
> Henrik
>
Received on Tue Aug 15 2006 - 12:08:15 MDT
This archive was generated by hypermail pre-2.1.9 : Fri Sep 01 2006 - 12:00:02 MDT