John,
After looking at the gemstone code[1] and comparing to the pharo code[2], it looks like a GemStone bug ... without digging in deeper, I'd guess that either there are no Zinc tests to validate the format of ZnDigestAuthenticator class>>md5Hash: or we are failing the test:)
Looks like we should have implemented the method as follows:
md5Hash: aString
| hash |
hex := aString md5sum hex.
hash := hash hex asLowercase.
(hash beginsWith: '16r') ifTrue: [ hash := hash allButFirst: 3 ].
hash := hash padded: #left to: 32 with: $0
^hash
I've opened an issue on the GLASS zinc project[3] to track this problem ...
Let me know if this works for you,
Dale
[1] https://github.com/glassdb/zinc/blob/gemstone2.4/repository/Zinc-HTTP.package/ZnDigestAuthenticator.class/class/md5Hash..st
[2] https://github.com/svenvc/zinc/blob/master/repository/Zinc-HTTP.package/ZnDigestAuthenticator.class/class/md5Hash..st
[3] https://github.com/glassdb/zinc/issues/40
From: "John McIntosh" <[hidden email]>
To: [hidden email]
Sent: Sunday, June 2, 2013 4:46:54 PM
Subject: [GS/SS Beta] md5Hash zero padding?
ZnDigestAuthenticator md5Hash: '1C6636B9B516-3B8A-7134-42FA-10A3352F'.
In my glass server (not current) I noticed that the above gives different results depending on if you execute in Pharo, or in Gemstone. It seems the Pharo code pads on the left with zero out to 32 bytes.
On the Gemstone side, no padding, and later since it is a string we are throwing about you get a difference in a validation compare and take the failure path...
--
===========================================================================
John M. McIntosh <
[hidden email]>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================
Locked
