Changes to your user object shouldn't get persisted until the session flushes at the end of the transaction. But things get fuzzy here for me since I am not really an expert on Hibernate/Spring transactions.
You call UserManager.save(user) right after the code below, right? So somehow the transaction that loaded user (in prepare maybe), is getting flushed before you run UserManager.save? Is it because each call to UserManager is a new transaction/session when called from the action? If that is the case then I think you do need to create your own service layer method that does this so it call all be wrapped in one big transaction, since the Action itself is not transactional. In the interest of full disclosure, I have confused myself, but since Rob is smarter than me I am going to go ahead and see if he can figure out if what I said is useful or not. Rob Hills wrote: > > 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] > > > -- View this message in context: http://www.nabble.com/Appfuse-2.01-%2B-Struts-%2B-modified-core-classes--%3E-password-confusion-tp15397967s2369p15548075.html Sent from the AppFuse - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
