17 Nov
2009
17 Nov
'09
10:05 p.m.
On Tuesday 17 November 2009, Jan Janak wrote:
On Tue, Nov 17, 2009 at 5:12 PM, Alex Hermann
<alex(a)speakup.nl> wrote:
^^^^^^
Jan,
On Tuesday 17 November 2009, you wrote:
How does the server know that the credentials are valid and it can
thus send back stale=true? Note that you can only use that parameter
if you verified that the username and password is valid (by verifying
the response string). Here is relevant text from RFC2617:
stale
A flag, indicating that the previous request from the client was
rejected because the nonce value was stale. If stale is TRUE
(case-insensitive), the client may wish to simply retry the request
with a new encrypted response, without reprompting the user for a
new username and password. The server should only set stale to TRUE On Tue, Nov 17, 2009 at 4:13 PM, Alex Hermann
<alex(a)speakup.nl> wrote:
The server can just as well generate a stale=true
response immediately,
independent of the credentials check. If later on a non-expired nonce
arrives, it can do the credentials check and send a response without
stale=true if necessary. if it receives a request for which the nonce is
invalid but with a
valid digest for that nonce (indicating that the client knows the
correct username/password). If stale is FALSE, or anything other
than TRUE, or the stale directive is not present, the username
and/or password are invalid, and new values must be obtained.
In other words, you can move the expired nonce check to the beginning
of the authentication process, but in that case you should make sure
that you never send back stale=true.
The text says _should_, which in normal RFC terms means that the
implementation may choose not to do it if it has a good reason to do so
rfc2119:
"
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
"
I think that halving the DB load on auth attempts is a good/valid reason, and
I don't see how this could go wrong:
1) 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.
The server gets a little bit more traffic if there are a lot of clients
configured with wrong credentials, otherwise, the traffic is the same but the
DB load halves.
2) If the nonce is not stale: no changes to current behaviour.
--
Met vriendelijke groet,
Alex Hermann
SpeakUp BV
T: 088-SPEAKUP (088-7732587)
F: 088-7732588