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 > 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.
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. Agreed. > 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... Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
