Steps to reproduce:

1. Log in to Drupal in your "default" web browser. (The browser that is opened when you click a link in your email.)
2. From another browser, request a Password reset email.
3. Click the Password Reset link in the email.
4. You'll receive a message in your default browser that you are already logged in, with a link for 'Change your password.' Click the link.

Result:
The resulting edit form requires the old password. But the user expected to be able to change their password, possibly because they don't know their old password anymore.

Expected result:
After confirming identify with the email link, the user should be able to set a new password without providing the old one.

Current work-around:

The user should log-out before clicking the link in the email.

Suggested solutions:

a) The 'Change my Password' link generated by user_pass_reset() should include the token that is required to disable the current password field on the user edit form.

b) or, the user's existing session should be destroyed at the beginning of user_pass_reset(), so that they are provided the same experience as users without an existing session.

Yes, this is largely a PEBKAC due to users who don't understand that they may have more than one browser on their system. BUt these users do exist, and some of them have accounts on Drupal sites. :-) And, it is in fact a strange inconsistency in the way user_pass_reset() works now that we have the current password field, so we should fix it.

Comments

crifi’s picture

crifi CreditAttribution: crifi commented
Category: bug » task
Priority: Normal » Minor

In my opinion your suggestion will cause overhead of code in drupal core. Since the described behavior works by design, this is definitely no bug.

mpotter’s picture

mpotter CreditAttribution: mpotter commented

In case other people run into this, I created a sandbox project in D7 that handles this. It's a very simple menu_alter that destroys the current session if the user is already logged in before processing the reset-password link.

http://drupal.org/sandbox/mpotter/1872282

I agree with the original poster than the current behavior in Drupal core is not ideal and does not make for a good user experience. On the specific client site I was working on, we had an ecommerce site subscription and the user was automatically logged-in after making their subscription purchase to allow them to view their purchased content immediately. In the meantime they get the normal Drupal email regarding their user account that was automatically generated for them when they purchased content. Since they were automatically logged into the site already, clicking the reset-password link in their email would always fail, causing a lot of confused users.

Seems like the behavior to log out existing users when using password-reset should at least be an option in the Drupal admin for D8.

matt2000’s picture

matt2000 CreditAttribution: matt2000 commented
Category: task » bug
Priority: Minor » Normal

I don't think it's "by design" that a user who wishes to change their forgot password may need their password in order to do so. This is a bug.

Also, as mpotter has demonstrated, there are solutions with trivial code changes. There's no additional overhead. We simply need to find consensus on which of the possible solutions is best for most users.

sidharthap’s picture

sidharthap
Primary language English
CreditAttribution: sidharthap commented

I think the best may be to provide a setting for this in users setting page and depending upon the configuration the user_pass_reset() will enable and disable the current password field.

Nephele’s picture

Nephele CreditAttribution: Nephele commented
Status: Active » Closed (duplicate)

This is a duplicate of #1872404: One-time password link has broken message if the user is logged in, which provides a patch to fix the immediate bug. The larger issue of improving the password-reset system is being addressed by #75924: Include fields for resetting password on the one-time password reset page.