Thanks for answer. I'm sure that the byte representation is printable, because that's a very easy algorithm, and it is working since some year storing correct encrypted password with the other application. What i should need is an inverse operation of the HexUtils.convert. Is there such an algorithm? I 'll explain better. Lets call this inverse operation convert_inv. It should be so that
HexUtils.convert (convert_inv(myAlgorithm(myClearCredential)))=myAlgorithm(myClearCredential). So including convert_inv in myAlgorithm (while the other application follow with the original one) I solve my problem. Is it possible? Thanks for help Alessandro On 3/22/06, Jay Burgess <[EMAIL PROTECTED]> wrote: > > I think this is the right answer: > > digest() returns a sequence of bytes. Depending on the values of the > individual > bytes, if you were to try and convert it to String, you can end up with > non-printable characters, etc. > > I'm assuming that HexUtils.convert() turns each 4 bits of each byte into a > hex > character, so that you end up with a proper String representation of the > digest > that can be sent as part of a URL. > > Jay > > | Jay Burgess [Vertical Technology Group] > | http://www.vtgroup.com/ > > > -----Original Message----- > From: Alessandro Colantoni [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 22, 2006 12:12 PM > To: Tomcat Users List > Subject: return (HexUtils.convert(md.digest())) in RealmBase > > Hi All! > I saw that both method Digest(..) and digest(..) in RealmBase return ( > HexUtils.convert(md.digest())) and not just > md.digest().toString. > > My problem is that user table is maintained by another application > developed > in an other technology. > My application uses this table just to authenticate. > The password of user table is encrypted with an algorithm I've been done. > I wrote a MessageDigestSpi for that algorithm, I wrote my provider, I > registered it and everything looks work fine. > Except that of course if I do: > RealmBase.Digest(myCredentials,myAlgorithm); > > I get a result different from doing > MessageDigest md = MessageDigest.getInstance(myAlgorithm); > md.update(myCredentials.getBytes()); > md.digest().toString; > > but the same result of > MessageDigest md = MessageDigest.getInstance(myAlgorithm); > md.update(myCredentials.getBytes()); > HexUtils.convert(md.digest()) > > So the problem is that the other application stores without using the > HexUtils.convert method > but when tomcat authenticates it uses it. > > One solution could be write a Realm class that extends the JDBCRealm (the > one I'm using) and overwrite these methods. > But I'm afraid that in different versions of Tomcat (i don't want link to > one) could be different signature of these methods. > There's another solution? > At least avoiding overwriting these very important methods? > > And just for curiosity, why HexUtils.convert has been utilized? > > Thanks in advance for help and have a nice springtime > Alessandro > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
