Include fields for resetting password on the one-time password reset page

Created on 27 July 2006, over 18 years ago
Updated 29 May 2024, 7 months ago

Problem/Motivation

When useres register for an account and follow their one-time login link, or requests a one-time-link because they forgot their password, the resulting user/edit form does not require them to choose a new password. If by chance they miss that part of the form (which happens quite often as it's not highlighted), they're left with the inital random password.

To make matters worse, when they return to the user account page to change their password later on, they are prompted to enter their OLD password - the one they have forgotten. This creates a terrible user experience for users, and a headache for site admins.

Proposed resolution

It would make for a better user-experience all around if the prompt to reset your password were on the one-time login page.

Remaining tasks

  • Update issue summary with screenshots.
  • Add simpletests.

User interface changes

None.

API changes

user_pass_reset():

  • moved the second phase (the form response) to user_pass_reset_submit().
  • Clarified the status message for already used links. Expired links are caught by the first if, so let's be specific here: In the end, a user needs to know if there are signs that a 3rd person could have used the link and taken over the user's account.
  • The status message for logged-in users: "You have already used this one-time login link. It is not necessary to use this link to login anymore. You are already logged in." is misleading. While it is true that it is not necessary to use this link, first of all it is also true that it is not possible anymore. Changed this to "You have already used this one-time login link, therefore you need to login with your password. In this case this is not necessary because you are already logged in."

user_pass_reset_submit():

  • To save the new password I'm straightly using user_save() unlike in patch #4 where a custom query was used. True, that user_save is a bit behemoth. But we need to do all checks, call all hooks, allow for alternate password hashing schemes etc. Certainly we don't want to reimplement or copy/paste that code. In the end using user_save is no problem because resetting the password is no performance-critical task.

user_pass():
The button title "E-mail new password" has been incorrect for quite a while. We're not sending passwords, but one-time login links. I changed the button title to "Request password reset" which is generic enough not to be incorrect, yet easy to understand.
Also, a description was added to the textfield.

user_pass_submit():

  • The message "Further instructions have been sent to your e-mail address." misses out the one-time login link and therefore leaves the user unclear about whether this means his action was successful or not. Changed to: "A one-time login link and further instructions have been sent to your e-mail address."
  • The redirect to the login page is confusing because logging in is exactly what the user can't do at the moment. Rather we should leave the user where s/he is. S/he anyway needs to check mail, first.

_user_mail_text():

  • Changed the e-mail text so it reflects our changes.
  • Maybe we can improve on some of the messages.

Also I wasn't sure if hook_user_login (invoked by user_authenticate_finalize) should be provided both password and username, so modules hooking in there can make use of the information (at that point there is not enough documentation about the hooks available). As hook_user_login currently doesn't get any useful information, going with what we have should be okay. If someone knows more about this aspect, I'd appreciate some info though.

Original report by joshk

When users register for an account and follow their one-time login link, or requests a one-time-link because they forgot their password, the resulting user/edit form does not require them to choose a new password. If by chance they miss that part of the form (which happens quite often as it's not highlighted), they're left with the inital random password.

It would make for a better user-experience all around if it were that newly registered users were required to choose a password which they can remember. This would mean:

1) Making the password fields required for the one-time-login form
2) Give the password section of the form a very light weight to put it at the top

I'll create a patch for this unless there's a compelling reason not to.

Feature request
Status

Active

Version

11.0 🔥

Component
User system 

Last updated about 4 hours ago

Created by

🇺🇸United States joshk

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024