Re: unable to login to second application because of password digest issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, Martin Gainty wrote: > MessageDigester.digest() returns an array of bytes this will produce > a DataType conversion error to/from String without constructing a new > String datatype Nobody is trying to to convert to/from a String inappropriately. The code is correct. Your comment is confusing. > the bigger problem is digest does 'padding' No, it doesn't. SHA-1 does not do any padding. This comment is incorrect. > so the only way to get back the original string is: keep the > MessageDigest in a local instance variable then revert the padding to > the local string with MessageDigest.reset() //then finally produce a > String representation of the original contents with > MessageDigest.toString() MessageDigest.toString does not return the original string, nor does it return the hexadecimal-encoded string shown by the OP. Calling reset does nothing, here. This comment is confusing AND incorrect. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklRgkUACgkQ9CaO5/Lv0PCIpQCePe8i1GypKrP+54Q2pfXLfRsb e20AoJcXjd6MW2fjeiPBNDTjjpAi0i08 =1MPL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: unable to login to second application because of password digest issues
MessageDigester.digest() returns an array of bytes this will produce a DataType conversion error to/from String without constructing a new String datatype the bigger problem is digest does 'padding' so the only way to get back the original string is: keep the MessageDigest in a local instance variable then revert the padding to the local string with MessageDigest.reset() //then finally produce a String representation of the original contents with MessageDigest.toString() HTH Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > Date: Sun, 14 Dec 2008 17:24:45 -0800 > From: removeps-gro...@yahoo.com > Subject: Re: unable to login to second application because of password digest > issues > To: users@tomcat.apache.org > > Nevermind, I figured it out. In the second request to login, there was an > extra line, so the password was actually "test\r\n". > > > --- On Sun, 12/14/08, removeps-gro...@yahoo.com > wrote: > > > From: removeps-gro...@yahoo.com > > Subject: unable to login to second application because of password digest > > issues > > To: users@tomcat.apache.org > > Date: Sunday, December 14, 2008, 2:55 PM > > Hi. I added a second application, but am unable to login to > > it because of password digest issues. Stepping into > > RealmBase.java this is what I find: > > > > When I log in to the primary application (under ROOT) the > > password is "test" and the password saved in > > the database is the sha1 which is > > "a743f6004188c384dbf566c0811ca0c978e07a9b". > > > > In JDBCRealm.digest, which is called by authenticate, there > > is a line > > > > return (HexUtils.convert(md.digest())); > > > > Incidentally, the second call to md.digest() returns a new > > result, although there is a call to md.reset() at the start > > of the try block. > > > > When I put HexUtils.convert(md.digest()) into the debug > > watch, I get > > > > HexUtils.convert(md.digest()) > > "a743f6004188c384dbf566c0811ca0c978e07a9b" String > > > > This matches what's in the database. Of course when I > > let the debugger continue the login fails because the code > > itself calls md.digest which returns a new result. > > > > So if I did not add that expression to the watch window, > > the login would work. And this is the case. > > > > Now onto my second application. The login is also > > "test", although the username, table name, and > > column names are different. > > > > However, When I put HexUtils.convert(md.digest()) into the > > debug watch, I get > > > > HexUtils.convert(md.digest()) > > "5fd0b97a45856c5581c1022c2e59ea00670e1040" String > > > > This does not match the value in the database, so the login > > fails. > > > > In fact, if I don't add any breakpoints and let the > > code run, the login fails, and my guess is that's > > because digest returns the wrong value. By contrast, for > > the ROOT application, digest returns the right value and the > > login succeeds -- as long as there are no breakpoints and > > watch variables. > > > > Incidentally, in both cases, the next call to > > HexUtils.convert(md.digest()) yields > > > > HexUtils.convert(md.digest()) > > "da39a3ee5e6b4b0d3255bfef95601890afd80709" String > > HexUtils.convert(md.digest()) > > "da39a3ee5e6b4b0d3255bfef95601890afd80709" String > > > > And the value remains the same even for the next call to > > HexUtils.convert(md.digest()). > > > > Strange problem. > > > > Thanks. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > _ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008
Re: unable to login to second application because of password digest issues
Nevermind, I figured it out. In the second request to login, there was an extra line, so the password was actually "test\r\n". --- On Sun, 12/14/08, removeps-gro...@yahoo.com wrote: > From: removeps-gro...@yahoo.com > Subject: unable to login to second application because of password digest > issues > To: users@tomcat.apache.org > Date: Sunday, December 14, 2008, 2:55 PM > Hi. I added a second application, but am unable to login to > it because of password digest issues. Stepping into > RealmBase.java this is what I find: > > When I log in to the primary application (under ROOT) the > password is "test" and the password saved in > the database is the sha1 which is > "a743f6004188c384dbf566c0811ca0c978e07a9b". > > In JDBCRealm.digest, which is called by authenticate, there > is a line > > return (HexUtils.convert(md.digest())); > > Incidentally, the second call to md.digest() returns a new > result, although there is a call to md.reset() at the start > of the try block. > > When I put HexUtils.convert(md.digest()) into the debug > watch, I get > > HexUtils.convert(md.digest()) "a743f6004188c384dbf566c0811ca0c978e07a9b" > String > > This matches what's in the database. Of course when I > let the debugger continue the login fails because the code > itself calls md.digest which returns a new result. > > So if I did not add that expression to the watch window, > the login would work. And this is the case. > > Now onto my second application. The login is also > "test", although the username, table name, and > column names are different. > > However, When I put HexUtils.convert(md.digest()) into the > debug watch, I get > > HexUtils.convert(md.digest()) "5fd0b97a45856c5581c1022c2e59ea00670e1040" > String > > This does not match the value in the database, so the login > fails. > > In fact, if I don't add any breakpoints and let the > code run, the login fails, and my guess is that's > because digest returns the wrong value. By contrast, for > the ROOT application, digest returns the right value and the > login succeeds -- as long as there are no breakpoints and > watch variables. > > Incidentally, in both cases, the next call to > HexUtils.convert(md.digest()) yields > > HexUtils.convert(md.digest()) "da39a3ee5e6b4b0d3255bfef95601890afd80709" > String > HexUtils.convert(md.digest()) "da39a3ee5e6b4b0d3255bfef95601890afd80709" > String > > And the value remains the same even for the next call to > HexUtils.convert(md.digest()). > > Strange problem. > > Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
