A client forgot his password and used the 'request password' link. Once using the emailed one-time login link, he went to edit his user account to change his password. However, the form requires he enter his old password in addition to the new passwords. The problem with this is that he doesn't know his old password to begin with. This leaves a situation where passwords have to be changed manually by site admins and told to clients before they can change their passwords.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | Request_New_password_4.png | 70.99 KB | Simon Naude |
| #1 | Request_New_password_3.png | 35.79 KB | Simon Naude |
Comments
Comment #1
Simon Naude commentedComment #2
Simon Naude commentedComment #3
Simon Naude commentedComment #4
Simon Naude commentedComment #5
dcam commentedVanilla Drupal core should not do this. You need to let us know what contributed (non-core) modules that you have enabled. If you have any enabled that could alter the user form then try disabling them to see if the problem is fixed.
Comment #6
David_Rothstein commentedRight, when you use the one-time-login link you get redirected to a URL like
http://example.com/user/2/edit?pass-reset-token=[some-long-token]and with the valid token in the URL, Drupal removes the "Current password" field from the form and allows you to change the password without knowing your current one.A possible cause of this would be a module that is doing an Ajax request on the form and interfering with the above (see comments at http://drupal.stackexchange.com/questions/20947/user-cannot-change-passw... as well as #1858486: Ajax call breaks Password Reset).
Another possible cause would be if the user navigates somewhere else first (or the site redirects them somewhere else first) so they don't wind up with the token in the URL. (You mentioned "Once using the emailed one-time login link, he went to edit his user account" but he shouldn't have to go there normally; normal Drupal behavior would direct him there automatically right after they use the password reset link.)
Comment #7
darrellduane commentedThis issue is a duplicate of this issue which has been resolved: https://www.drupal.org/node/889772
Comment #8
David_Rothstein commentedIt's not clear from the report that the user was logged in at the time, so it's not necessarily a duplicate of that issue. But it could be, or it could be one of the other things listed above.... either way, no further information was provided after two years, so it should be safe to close this. If someone has more specific steps to reproduce the problem, feel free to reopen the issue.