Odi, the patch looks fine to me. I just dislike this part:
try {
cnonce = createCnonce();
} catch(AuthenticationException e) {
throw new RuntimeException(e.toString());
}
At the very least I would rethrow the exception as
MalformedChallengeException, or, preferably, change createCnonce to
throw MalformedChallengeException instead of AuthenticationException in
the very first place.
As to the stateful authentication framework, it sounds like a reasonable
improvement, but I suggest that we hold it off until the comprehensive
API redesign that should follow the 2.1 release. Feel free to file a bug
report meanwhile.
Cheers
Oleg
On Wed, 2003-09-17 at 10:13, Ortwin Gl�ck wrote:
> Take 2:
>
> - DigestScheme requires a nonce in every challange now
> (according to RFC 2617) test cases changed accordingly
> - included Olegs feedback
>
> After reading RFC 2617 I came to the conclusion, that we need to rework
> out authentication mechanism to support stateful authentication retries.
> Digest Authentication requires you to keep track of the number of times
> authentication has been retries (NC) and to calculate some values only
> on the first time etc. This can be achieved by making the DigestScheme
> more stateful (a1) and by changing authenticator to keep the
> DigestScheme instance across retries and pass in the challenge each time.
>
> Odi
>
> Oleg Kalnichevski wrote:
>
> > Odi,
> > The patch looks fine to me. There is just a few minor points that I
> > would like to be considered before the patch is committed:
> >
> > - DigestScheme#DigestScheme( String ) constructor should probably log a
> > warning message or even throw an exception if it encounters an
> > unrecognised 'qop' element. Currently they are just silently ignored.
> > - Use StringBuffer to concatenate strings in DigestScheme#createDigest(
> > String, String ).
> > - A test case for unsupported qop in HTTP Digest authentication would be
> > nice.
> > - The patch makes a few public methods private (quite appropriately in
> > my opinion). Nobody is going to miss them, I think, however, the fact of
> > 2.0 API breakage should be reflected in API_CHANGES_2_1.txt
> >
> > Cheers
> >
> > Oleg
>
> ______________________________________________________________________
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
