This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Questions while implementing UserDetailsManager#changePasswordPage Title Module

Questions while implementing UserDetailsManager#changePassword

I'm writing a JpaUserDetailsManager, which implements UserDetailsManager. Everything was going along just dandy, until I saw the method on UserDetailsManager

Code:

public void changePassword(String old, String new)

. The javadoc says,

Modify the current user's password. This should change the user's password in the persistent user repository (datbase, LDAP etc) and should also modify the current security context to contain the new password.

This threw me, because all of the other methods that I have to implement give me the current username, but this one doesn't. "Ok," I say to myself, "different, but still implementable, assuming I can get the user from the current context."
Two questions:

How do I get the current user?

How do I modify the current security context to contain the new password?

In fact you are probably better not to change the security context unless you need the password in memory for some reason. The AuthenticationManager can be configured to remove the credentials information from the Authentication object post-authentication, and this is the default behaviour in 3.1.

So I would just go with updating the storage and forget about the context. There's no reason in the average application why you would need to retain the password information for the user. I'll update the 3.1 Javadoc accordingly.

Comment

In fact you are probably better not to change the security context unless you need the password in memory for some reason. The AuthenticationManager can be configured to remove the credentials information from the Authentication object post-authentication, and this is the default behaviour in 3.1.

So I would just go with updating the storage and forget about the context. There's no reason in the average application why you would need to retain the password information for the user. I'll update the 3.1 Javadoc accordingly.

Ok, I'll do that. Is the way I plan on doing that above the recommended way to get the current user?

It just seems so odd that all of the other methods on UserDetailsManager give you the information you need to find the user, except for changePassword(String,String). I expected it have the signature "void changePassword(String username, String oldPassword, String newPassword).

Thanks,
Matthew

Comment

That method will be invoked in response to a user action, while they are logged in. So there is no need to pass in the username as it will always be the current user. That isn't the case for any of the other user management methods.