Announcement Announcement Module
Collapse
No announcement yet.
Questions while implementing UserDetailsManager#changePassword Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Questions while implementing UserDetailsManager#changePassword

    Hi all,

    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:
    1. How do I get the current user?
    2. How do I modify the current security context to contain the new password?
    For #1, I'm thinking that this is correct:
    Code:
    String username = SecurityContextHolder.getContext().getAuthentication().getName();
    I can get the actual JPA user entity from there. Please confirm.

    For #2, I'm thinking:
    Code:
    SecurityContextHolder.getContext().setAuthentication(new UsernamePasswordAuthenticationToken(username, newPassword));
    Is this correct? Please confirm.

    Thanks,
    Matthew

  • #2
    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


    • #3
      Originally posted by Luke Taylor View Post
      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


      • #4
        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.

        Comment


        • #5
          Ok, then. Is the way I plan on doing that above the recommended way to get the current user?

          Comment


          • #6
            Originally posted by matthewadams View Post
            Ok, then. Is the way I plan on doing that above the recommended way to get the current user?
            The SecurityContextHolder is one correct way to obtain the current user.

            Comment


            • #7
              Thanks!

              Comment

              Working...
              X