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