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
