Author orsenthil
Recipients ajaksu2, cmb, danohuiginn, jjlee, orsenthil
Date 2009-11-15.08:32:44
SpamBayes Score 5.81811e-05
Marked as misclassified No
Message-id <1258273967.23.0.363630262581.issue4683@psf.upfronthosting.co.za>
In-reply-to
Content
Interesting issue. RFC 2617 supports the claim. In RFC 2617, section
3.2.2 The Authorization Request Header, we see that nonce-count is
maintained for each particular nonce value and it can used by the server
to verify the replays.

"""
The nc-value is the hexadecimal count of the number of requests
(including the current request) that the client has sent with the nonce
value in this request.  For  example, in the first request sent in
response to a given nonce value, the client sends "nc=00000001".  The
purpose of this  directive is to allow the server to detect request
replays by  maintaining its own copy of this count - if the same
nc-value is  seen twice, then the request is a replay. 
"""

resetting the nonce_count for each new nonce is the correct thing to do.
Patch seems okay and I going ahead with that.

We don't have test for HTTPDigestAuth yet, the nonce tests should be a
part of that.
History
Date User Action Args
2009-11-15 08:32:47orsenthilsetrecipients: + orsenthil, jjlee, ajaksu2, cmb, danohuiginn
2009-11-15 08:32:47orsenthilsetmessageid: <1258273967.23.0.363630262581.issue4683@psf.upfronthosting.co.za>
2009-11-15 08:32:45orsenthillinkissue4683 messages
2009-11-15 08:32:44orsenthilcreate