Hi Matt, Well, after a little diversion to set up so I could trace into UserManagerImpl, I've worked out what's happening, but not why...
On 10 Feb 2008 at 13:47, Matt Raible wrote: > In 2.0.1, password encryption logic moved into the service layer. > > http://issues.appfuse.org/browse/APF-666 > > Click on the FishEye link to see the changes committed to SVN. > > Maybe that has something to do with your issue? In prior versions, the > logic depended on a "encryptPassword" hidden field being created (by > JavaScript). When I trace through the UserManagerImpl.save(User) method, I find that at line 87, the code uses the dao to pull the user's old password from the DB to compare it with the one that's just been posted to see if it's changed. The problem I see here is that the password that comes back from the DB is the one I typed in to the form - in plain text. Somehow it's been persisted to the DB prior to UserManagerImpl.save(User) being called. To backtrack a little, when this happens, I'm logged in as an administrator and am editing another user's record. I must confess to being a little nervous about the one User object being used in UserAction to handle both the logged in user and the User being edited. I'd have thought it would be safer if a different user object was used when editing another user's profile, but I guess this code has worked fine for everyone else for some time so the pattern is presumably OK. I'm still not sure what I've done to change this behaviour but will keep hunting to see if I can work it out. > On 2/10/08, Rob Hills <[EMAIL PROTECTED]> wrote: > > Hi All, > > > > My app is based on Appfuse 2.0 (manually upgraded to 2.01) and Struts. > > > > I modified the core classes to add a "Company" attribute to the User object. > > > > In testing I've found a problem that I suspect is my fault, but I'm confused > > about what's going on. > > > > When I create a new user in my application, the password value in the db is > > encrypted as expected. However, if I use the user edit form to change the > > user's password (either by editing the user as an administrator, or logging > > in > > as that user and using "my profile"), the new password is stored in the db > > as > > plain text. Of course, the next time that user tries to login, it fails > > with an > > invalid password. > > > > I've looked back at the original org.appfuse.webapp.action.UserAction class > > and compared it with my modified version but I can't see where the > > password encryption takes place, or what I may have done to stop that > > happening. > > > > I assume that this works correctly in an unmodified Appfuse app, so can > > someone please explain to me where the password encryption happens so I > > can work out how I've broken it? Cheers, Rob Hills Waikiki, Western Australia Mobile +61 (412) 904-357 Fax: +61 (8) 9529-2137 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
