Hi again Matt, I've now worked out where it's happening, but still not why :-(
The reason I have messed with the User class is that each user belongs to a Company. The business rules are that a user can't change company. In my UserAction.save() method, I have the following code: User oldUser = userManager.getUser(user.getId().toString); user.setCompany(oldUser.getCompany()); The aim of the code is to ensure the user doesn't try to change their company. Unfortunately, the first line makes Hibernate persist the changes to my user object to the db - I've confirmed this by checking the db before and after this line is executed. So that's how the plain password gets in there. I believe I can work around this by using a CompanyManager, but my question is, why is this happening? Is there any way I can get the user's old Company at this point without Hibernate helpfully flushing the user's updated details for me? On 12 Feb 2008 at 0:03, Rob Hills wrote: > 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]
