Fix incorrect message after resetting password

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Reroll the patch as #14 is not getting applied to the current version so rerolled the patch to make it compatible and attaching reroll_diff.

The last submitted patch, 21: 2969406-21.patch, failed testing. View results →

Giving a new patch for 10.1 as provided patch in #21 failed

The last submitted patch, 23: 2969406-23.patch, failed testing. View results →

I am working on this.

Providing a patch for 10.1.x as Patch #23 failed.

Please review.

Thanks.

The last submitted patch, 28: 2969406-27.patch, failed testing. View results →

Created MR for the issue, please review.

Thank you.

Fixed Test.

Usability review

We reviewed this issue at 📌 Drupal Usability Meeting 2023-03-17 Fixed .

That issue will have a link to the recording, for the record the attendees were: myself, @rkoller, @simohell, @shaal and @blackbamboo.

After considering several options, we recommend the following text for the message:

You have logged in with your one-time login link. Set your new password now, it is not possible to use this link a second time.

Updated message as per Usability review team feedback.

Thanks, moving to RTBC.

I know a lot of people who use one-time login links to log in all the time and never change the password (and have forgotten it long ago). "Set your new password now" gives the impression that you have to set the new password in order to continue, when in fact you can set your new password, but you don't have to. Perhaps "You can set your new password now" would be more appropriate than "Set your new password now".

I think #40 is worth exploring - do you have any thoughts on changing it from 'Set your new password' to 'You can set your new password' @AaronMcHale?

To keep this moving I don't see an issue with updating to "You can set your new password"

Though not sure about the one-time login approach. Seems to bypass all the password security.

Sorry about the delay in replying here.

My view is that with the message we want to convey a sense of urgency, because for most users they will be using these links to access their account after they have opted to reset their password, usually because they forgot it, so we want to emphasise to the user that they must set a new password now, otherwise they will be in effect locked out of their account and will need to do the same process again next time they try to login.

While it is true that people do use the one-time-login links for accessing a site during development/testing (I have done this myself on many occasions), I don't see that being the intended use case of this feature. For people who use these links in that way, they probably already know that they don't need to actually set a password now and next time they need to login can use the same process. The users who really need this message are the normal users who have forgotten their password and actually do need to set it now.

In an ideal world these links would go to a dedicated set password form, rather than the general account edit form, and in that way, we can focus the attention of the user. While at the same time, we would have a dedicated way of generating links for the dev/test use-case and those links would take you to a more appropriate place with more appropriate messaging, maybe that's a good candiate for a follow-up issue!

In that case I think it may be fine to leave as is.

I have updated the Issue Summary with the standard template and before and after screenshots.

Is Set your new password now, it is not possible to use this link a second time. an example of comma-splice sentence?

Is [...] an example of comma-splice sentence?

I am by no means an expert in these areas, so I cannot confidently say.

Reading the sentence it has two parts: "Set your new password now" is the action we want the user to perform; And in the same sentence we provide the reason why they must do it now: "it is not possible to use this link a second time."

That to me feels like a suitable sentence as is, but again I'm by no means an expert and would not object to swapping the comma with a semicolon.

I checked with some on-line grammar checkers and got mixed results. Some changed the comma to a semi-colon, others did not.

But is that final phrase even needed. The first sentence states clearly that it is a 'one-time' login link. Why not just, 'You have logged in with your one-time login link. Set your new password now.' Or even a simple third sentence. 'You have logged in with your one-time login link. The link can not be used again.' But I too, am not skilled in proper written English.

I think You have logged in with your one-time login link. Set your new password now. is preferable to You have logged in with your one-time login link. The link can not be used again. because it makes explicit a new password should be set.

I like the suggestion given in #49, Although the third sentence is kind of redundant because one-time login link actually means that it cannot be used again.

Also, I think that "Change your password now" is giving a very urgent message which is not required, because no matter what, the user can get a one-time login link again if he doesn't change the password just now.

So, if we could add something like Change your password to something you can remember the next time or rather Set up your secure password for the next time.

What I can say is that we generally prefer shorter messages, if there's a short and concise way to get to the point, we should go with it.

So with that in mind, I think @quietone makes a good point in comment #49:

But is that final phrase even needed. The first sentence states clearly that it is a 'one-time' login link.

In fact, I think we could shorten it even further, we can replace "logged in with your" in the first sentence with simply "used a", so then it simply reads:

"You have used a one-time login link. Set your new password now."

On further reflection I now feel the extra statement "it is not possible to use this link a second time" is not adding any value, and as long as the user sets their password, they do not need to know that the link cannot be used again.

In addition, we could potentially have a follow-up issue to look at improving the experience for when an out-of-date login link is used, because right now you simply get an access denied page, which is not very helpful.

I am adding a link to 📌 Remove "Please" from the codebase Fixed in the "Remaining tasks" section of the issue summary.

Hi I update the message following comment #52, I also rebased please revise.

There are failing tests for both the patch and the MR.

The message is wrong in case the destination parameter is used. For example, if one appends ?destination=/node to the one-time login link, one gets redirected to /node?check_logged_in=1, then it says "...set your password now...", but it is impossible to do so at this point, because now navigating back to user edit form, it is necessarily to know your current password to set a new one. Perhaps a different message could be shown if the "destination" GET parameter is set.

This issue will need an update, since 📌 Remove "Please" from the codebase Fixed was fixed.

Updated the MR. And it was quicker to make a patch for 11.x than go through the process of making another MR. There is no interdiff with the latest patch because that patch did not match the 10.1.x MR at the time.

I have updated the After screenshot in the issue summary.

Text update makes sense to me.

I personally agree with the notion that "Set your new password now" feels like a bit too direct and has too much urgency. Probably the biggest issue I have is that the message makes it sound like the user must set a new password, but the page where we redirect doesn't actually require the user to set a new password. Because of this, I think we should try to adjust the message accordingly. It feels that something along the lines of "'You can set your new password now" would be more suitable.

While I personally like "You can set your new password now" more as well, this problem was already addressed in #40 and #43 and should go in a follow-up issue.

I don't think #43 fully addresses #40. I'm not concerned about the impact of this for people who use the one-time-login links for accessing a site during development/testing. This group of users are probably ignoring the message altogether anyway. I'm more concerned about the fact that the text in this context appears out of place, even a little bit rude because it's so direct. I'm not a native English speaker so take that with a grain of salt. I also think it would be totally reasonable to display this text if we redirected the user to a form where they must set a new password. However, since we are not doing that and instead we redirect them on a more generic form, it feels like a direct order for the user. After all, there isn't anything wrong if the user doesn't set a new password, they can still ask for a new one-time-link using the UI when they need to login next time.

I feel pretty strongly that we should soften the language a little bit, and open a follow-up to improve the whole login experience. Once we have a form that is focused on setting a new password, we could change the language to be more direct since then in fact the user would have to set a new password.

Tagging needs followup for the comment in #65

After all, there isn't anything wrong if the user doesn't set a new password, they can still ask for a new one-time-link using the UI when they need to login next time.

We can assume that somebody who clicked on a link to reset the password, read the email sent for that purpose, and clicked on the link given in the email, wants to reset the password, which means setting a new password.
In English, direct commands are avoided, when possible. (That does not mean they are not used.) Since we are avoiding to use please as per another issue, the only possibility is using You could set a new password now. or You can set a new password now. (I gather the first is preferred when a person wants to be polite.)

Since UserController::resetPassLogin() does not show the form to change the password, the message should also give a link to the form to edit the password.

I noted in command #52 that we generally prefer shorter message, but more people seem to prefer adding "You can" to soften the message, and on reflection, there is something a little bit nicer about the less direct phrasing. I don't feel particularly strongly one way or the other, so I won't object to "You can set your new password now." It does still feel like a fairly short and concise message.

In comment #59 @alberto56 made a good point about how if the user uses the destination parameter, then that sentence doesn't make as much sense. I think there's still value in keeping it, but we could wrap it in a link to the user edit form.

So, if the user landed on any route other than the user edit route, the message could be something like You have used a one-time login link. [You can set your new password now.](/user/1/edit)

In comment #65 @lauriii made a good point that we should open a follow-up issue to have a more focused form, and I totally agree with this. It made me think about how the current password reset process is not really that fit for purpose regardless of which of the two main use-cases:

1. User resetting their password: The current process is not ideal because it takes the user to the user edit form, which as noted, is not focused and could overwhelm or confuse the user, as they might not know exactly what action they are supposed to take next.
2. Using Drush to generate a one-time-login link: I've been doing this a lot lately, and it's really clear that the current process is also not optimal for this because the user edit form is not the most helpful starting point.

On the second point, the work being done on the new Dashboards in Core may result in changes to what happens when the user logs in, for instance it might take them to the admin Dashboard instead of the user page.

We could build on this by designing a more tailor one-time-login-link process for those who just need to login but not reset the password. We could add a new route dedicated to this process which instead of taking people to the user edit form (or a future password reset form) takes people to the same place they go after they have logged in (whether that be their user page or a future Dashboard), along with adding a new user:login sub-command (similar to Drush) for the drupal console utility.

So there's potentially a couple of follow-ups there.

The code in UserController::resetPassLogin() (including the part showing the message) seems to assume that:

• People are effectively redirected to the page containing the form to edit their account data (including their password)
• The form elements to edit the password are the first form elements in account edit form

A contributed module could force a redirect to another page. Seeing You can set a new password now. most people would probably think they are on the page where they can set a new password and they could get confused, if they are redirected to another page that does not contain the form to edit their account.
From /admin/config/people/accounts/form-display, site administrators could have changed the position of the username and password fields, or the same can be done from a contributed module. The password field could not be immediately visible and people could not understand they are on the page that allows that.

I understand that does not happen out-of-the-box in a plain Drupal installation, but the shown message should consider that.
For example, with messages similar to You can set your new password now., people could expect they are on the page to edit their password; messages similar to You can set your new password. would probably not give them that expectation, but usually messages without links given with the messenger service are expected to be about the current page. The message given by user_user_login(), for example, is not Configure your account time zone setting. but Configure your account time zone setting. with a link that makes the form elements people should change visible in the page.

I think we can safely assume that the message will be displayed on a password edit form (although not necessarily the user edit form). If it wouldn’t, people could not reset their password, since they need to know their old password to set a new one.
If a contributed module introduces another workflow, it will likely change the status message as well.

It might be worth highlighting the password field on the user edit form, but this seems like a follow-up issue.

I agree with @RobinCS in comment #70.

If a site or contrib module changes the location where people are redirected to, then the change I proposed in comment #68 (adding a link if the user is not on the user edit form) would address that.

If a contrib module is doing more than that, for instance providing a dedicated password reset form, then it's up to the contrib module to also ensure that the message the user receives is appropriate. While we can facilitate contrib, in Core we can only account for what Core does, we can't account for all possible combinations of what contrib might do.

No, I meant it the other way around. The password-field on the user edit form is password-protected. When you forgot your password, you cannot set a new one. The only exception is directly after using the password reset link (the same request this message is shown). Moving from one page to another would lock the password field again, aborting the reset.

This is why we can assume that the user can set their password on whatever page their landing. Because there can’t be a second one. This also means we can’t link to the user edit form in the status message.

My suggestion therefore is: “You have used a one-time login link. You can set your new password now.” or “You have used a one-time login link. You should set your new password now.”

Moving from one page to another would lock the password field again, aborting the reset.

That is the exact reason for which showing a You can set a new password now. message does not make any sense, when users are not redirected to a different page.

There is no need to assume anything. It is sufficient to force the redirect to be toward the account edit form.

The password-field on the user edit form is password-protected. When you forgot your password, you cannot set a new one.

That's a great point, I completely forgot about that.

I wonder in that case if we should just drop the second sentence completely, so it's just "You have used a one-time login link." (or something similar).

My thinking being that in 80% of cases a user is clicking the link in the email, so they will get to the proper location (whether that be the user edit form, or another dedicated form which a contrib module could add). In the "20% case", that would most likely come up for someone who used e.g. drush uli to generate a one-time-login link and added a destination parameter because they know how to do that. In that case the user does not actually need to set their password, they just needed a convenient way to login.

I can't think of another situation where, in core, a user would not end up on the user edit page. Even if a contrib module or custom code is used, then that should then be altering the link in the email prior to it being sent to link to the alternative location, which I hope would have the appropriate password fields.

The password-field on the user edit form is password-protected. When you forgot your password, you cannot set a new one.

If users followed the link given in the email sent for resetting the password, they do not need to remember the old password; they can just set a new password. (The value set when users return to the site following the link given in the email is stored in the session.)

Somewhat related, and in case it might be useful to anyone, I have created a module which allows administrators to set a custom "unique log in" message for use-cases other than the standard "click-on-a-link-from-a-lost-password-email" workflow: https://www.drupal.org/project/uli_custom_workflow →

Going though the latest comments, these seem to be our options:

1. You have used a one-time login link.
2. You have used a one-time login link. You can set your new password now.
3. You have used a one-time login link. You could set your new password now.
4. You have used a one-time login link. You should set your new password now.

The following options didn't seem to be well liked:

1. You have used a one-time login link. Please set your new password now. (Don't use "please". #2921133)
2. You have used a one-time login link. Set your new password now. (Feels a bit too direct and has too much urgency. #63)

I just went ahead with "You have used a one-time login link. You can set your new password now." now, as it is the one that most people liked or felt neutral about.

Patch #77 looks good.

Seems #65 has not been addressed.

Tried to address the comment #65 and made the message more generic.
Please review this patch

Patch for 11.x as the patch #80 was not applying.

@ _utsavsharma your patch file and interdiff file are same. Please check interdiff once, as it doesn't show the difference between patch #80 and #83.

Thanks

The last patch is also missing a test change, see #77.

Updated the patch no 2969406-80.Added a test change as well

#87 says the password can be reseted with „this link“, without providing a link. If you mean the link in the browser bar, then the user is already on that site, so there is no need to link to the same site. Also, linking to any site would lock the password form again (#72).
@smustgrave You said #65 had not been addressed, but #63/#65 suggested „You can set your new password now“. What part of #65 has not been addressed?

Since it's still not stated what part of patch #77 needs work, I'm gone retest #77 and put it back to Needs review.

RobinCS → changed the visibility of the branch 2969406-fix-incorrect-message to hidden.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

robincs → changed the visibility of the branch 2969406-fix-incorrect-message to active.

The patch no longer applies to 10.1.x, because the text itself was changed from "[…] It is recommended that you set your password." to "[…] Please set your password." in #2828724 (Username enumeration via one time login route) → . However, #2921133 (Remove "Please" from the codebase) → reverted this again, so the current patch does apply to 11.x.

@Ranjit1032002 Could you please update this merge request so it points to '11.x'.

Updated the MR to use message

"You have used a one-time login link. You can set your new password now."

Created the follow up from #65 here 📌 Improve login experience as a whole Active

@aaronmchale saw your comments in #68 and if that needs to be broken up into smaller pieces we can.

Personally not a word smith and think the change may be rude but it seems blunt, but that appears to have been discussed at length just throwing in my 2 cents.

Seems the text has been agreed upon.

Updating credit

Committed to 11.x and cherry-picked to 11.1.x, 10.5.x, 10.4.x.

Although this is a bug, not committed to 10.3 and 11.0 due to the string change. Refer to https://www.drupal.org/about/core/policies/core-change-policies/allowed-... →

Thanks

quietone → closed merge request !3607

Automatically closed - issue fixed for 2 weeks with no activity.