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
https://issues.apache.org/bugzilla/show_bug.cgi?id=53096
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.

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).

Regards,

Brian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to