On Tuesday 17 November 2009 18:02:03 Jan Janak wrote:
- If the nonce is stale, stale=true is returned, the client tries again
without prompting the user. If then the server decides the digest was invalid, it returns a response without stale=true and the client will prompt the user.
Or the user agent may just as well give up, report an error or try again later. You may end up having UAs that fail to authenticate from time to time, which can be worse than more DB load on the server.
A nonce will(/should) only be reused by an UAC when it was accepted in an earlier request. So the credentials are highly likely to be correct.
An initial request has no credentials, so no stale=true is returned.
The only scenario of failure I can think of is this: the UAC reuses a nonce, it receives a stale=true response and concludes(*) the credentials are correct, so it resubmits with the new nonce. On the UAS however, the credentials are changed since the previous authenticated request so the resubmitted credentials with valid nonce are rejected without stale=true. Because of the earlier conclusion (*) the UAC doesn't ask the user for new credentials and stops. IMHO the UAC should only conclude the credentials are correct when it receives a non-failure code for the request.
I think this sequence of events is seldom and the behaviour of the UAC is so weird that I'm willing to take that risk.
I'll try to cook a patch that makes the nonce check before credentials check configurable and submit it properly.
I think that if you want to perform the stale nonce check early then disabling stale=true all together would be a safe bet.
That would make matters worse:
If an UAC sends valid credentials with an expired nonce and the UAS send back a 407 without stale=true, the UAC should give up or ask the user. Both of which are unwanted.