27 Apr
2011
27 Apr
'11
8:29 a.m.
Hi,
we came across an issue where a client expects an unexpired nonce to be
flaged by the stale=true flag in the Digest Authenticate header field.
I added this to the challenge function by using flag 8. The patch is
attached. I suspect that calling pre_auth again to check whether the
nonce is stale isn't the correct way to do this and am open to suggestions.
I also looked into using the pv_*_authenticate() functions but all the
database stuff is just getting crazy.
Best regards,
Martin
8:59 a.m.
Juha Heinanen wrote:
Martin Hoffmann writes:
Yes. RFC 2617, 3.2.1:
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
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.
Regards,
Martin
we came across an issue where a client expects an
unexpired nonce to be
flaged by the stale=true flag in the Digest Authenticate header field.
is that specified in some rfc or elsewhere?
5046
days inactive
5046
days old
4 comments
2 participants
participants (2)
-
Juha Heinanen -
Martin Hoffmann