Nevermind, I figured it out.  In the second request to login, there was an 
extra line, so the password was actually "test1111\r\n".


--- On Sun, 12/14/08, removeps-gro...@yahoo.com <removeps-gro...@yahoo.com> 
wrote:

> From: removeps-gro...@yahoo.com <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 "test1111" 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
> "test1111", 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

Reply via email to