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]
