tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r1303339 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/realm/ webapps/docs/changelog.xml
Date Tue, 24 Apr 2012 20:11:08 GMT
On 24/04/2012 20:51, Brian Burch wrote:
> Sorry I haven't been able to quote the details of this commit made by
> markt a month ago, but I didn't keep a copy in my inbox.
> I previously submitted an enhancement to the corresponding test suite
> I fully expected all my test cases would succeed against mark's trivial
> bugfix.
> I recently brought my trunk sandbox up to svn: r1329909 and was puzzled
> to discover the relevant test case still FAILED!
> I've done a lot of digging and debugging, and come to the conclusion
> this problem is more subtle than originally thought. Does anyone know
> whether the current fix has been validated against a real android
> device? I suspect it doesn't work.

I certainly didn't at the time, but I can quite easily.

> The issues are:
> 1. the one line change:
> -        String md5a1 = getDigest(username, realm);
> +        // In digest auth, digests are always lower case
> +        String md5a1 = getDigest(username,
> realm).toLowerCase(Locale.ENGLISH);
> If I remember correctly, the intention was to be make tomcat more
> tolerant of clients that presented digest strings with upper case
> hexadecimal digits provided they were otherwise correct. The change in
> r1329909 seems to me as if it does nothing of relevance to that objective.


> 2. Client digest responses require an outer hash which will wrap one or
> two inner hashes... /if/ the inner hashes are (incorrectly) represented
> with upper case hex digits, then the outer hash will inevitably be
> different to the (correct situation) where they are represented with
> lower case hex digits. This difference is independent of whether the
> HTTP Digest header delivers its hashes using lower or upper case hex
> digits.
> 3. I have reworked the TestDigestAuthenticator class to explore these
> alternatives. I have also drafted a change to RealmBase that "fixes"
> situation 1 above, but it still fails with both cases of situation 2.
> 4. My suspicion is that /if/ the android digest algorithm (incorrectly)
> uses upper case hex digits with its outer hashes, it will probably also
> do the same with its inner hashes. If I am right, the two failing tests
> in situation 3 will not work until RealmBase has even more compensatory
> logic.
> I can explain and explore this in more detail, but I need a strategic
> decision first: do we back out the change and go to wontfix (i.e. wont
> be tolerant), or do we proceed with trying to be flexible? There must be
> a lot of androids out there carrying the "non standard" DIGEST logic
> (whatever that might really be).

Let me see what happens with 2.3.5 and 4.0.3 and decide then.

Watch this space...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message