We have the same issue on two applications based on appfuse. In one we did overwrite AppFuse's User class, but in the other, we did nothing.
The issue is not present in an artifact-generated app. A point to be noted is that we manually upgraded our two apps from AF 2.0 to 2.0.1 Christophe -----Original Message----- From: Rob Hills [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 10:24 PM To: [email protected] Subject: Re: [appfuse-user] Appfuse 2.01 + Struts + modified core classes -> password confusion Hi David, J. David Mendoza wrote: > What I did was: > 1. Extend the UserAction > 2. In the saveUser, i check if the password is less then 40 chars and > if it is I change the user's version to null (make Appfuse think this > is a new user) > > Doesn't work for every encryption method but it does for the sha... Thanks, I'll give that a try. It's good to know I'm not the only one who's had the problem. I think this workaround would also have a problem in the (low-probability) event that a user chose a very long password. It would be nice to know why it is happening and work out a way of stopping it, but your workaround should help in the meantime. > On Feb 12, 2008, at 10:39 AM, Rob Hills wrote: >> Many thanks for the reply. >> >> On 12 Feb 2008 at 7:57, Matt Raible wrote: >> >>> On 2/12/08, Rob Hills <[EMAIL PROTECTED]> wrote: >>>> >>>> On 11 Feb 2008 at 18:37, Rob Hills wrote: >>>>> In your UserDaoHibernate class, you have a getUserPassword method >>>>> which I notice manages to get the user's existing password from >>>>> the DB without triggering Hibernate to persist any edited user >>>>> details. I also note that your UserDao class covers this method >>>>> with the following annotations: >>>>> >>>>> @Transactional(propagation = Propagation.NOT_SUPPORTED) >>>>> >>>>> Is it this annotation that prevents the getUserPassword method >>>>> from triggering Hibernate to persist any unsaved edits to the User >>>>> object, or is it the fact that your query is simply returning a >>>>> String (rather than a User object)? >>> >>> The first option is correct. >> >> This issue is still causing me a major headache. To recap, my >> problem is that when I edit a user (either self-editing or >> administrator) if the password is changed, it's stored in the DB in >> plain text. >> >> I've worked out that the User edits are being written to the DB >> during the middle of my UserAction.save() method so when I call >> UserManager.save (which is the unchanged AppFuse one), its comparison >> of the "new" password with the DB version shows they're the same so >> it doesn't bother encrypting the password and it stays in the db in >> plain text. >> >> I thought my problem arose when I checked the user's company details, >> but it appears that anything I do during the UserAction.save method >> that uses another manager triggers hibernate to write the User edits >> to the db. Currently the trigger is the code that updates the user >> roles - AFAICT, this is identical to the original >> org.appfuse.webapp.action.UserAction code I based mine on. In that >> bit of code, the roleManager is used to update the user roles. >> >> I suspect there's something going on at a higher level than the >> UserAction class to trigger this behaviour. Do you have any >> suggestions about what to look for? Cheers, Rob Hills Waikiki, Western Australia --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
