One-time login & password reset links are truncated in plain-text emails

This is a pretty serious usability problem on the password reset emails, since the only way to log in when you request your password to be reset is to click the "one-time login" link. Don't know if this is fixed in later versions of Drupal, but for those of us who are still on 5.x, it would be good to have a fix.

In order to fix the issue on the password reset emails, I used the following code in user.module:

function user_pass_rehash($password, $timestamp, $login) {
  $rehash_pass = md5($password . $timestamp . $login);
  $rehash_pass = substr($rehash_pass, 0, 8);
  return $rehash_pass;
}

When I get a chance, I may code this into a proper patch for 7.x so we can get this looked at as a bug fix. I'm not sure about the security implications of the substr(), but I do think that we need these URLs to be shorter in order to support text-based mail clients.

Changing to "needs work".

More specific title.

This is a more general problem than just the password reset email, it applies to things like simplenews subscription confirmation where they have to click the link to confirm their subscription as well. Definitely need a permanent solution to this.

Good point, JeebsUK. Unfortunately, I don't think Drupal has a generic API function for generating these kind of URLs. I think the user_pass_rehash() function that I had to hack for my particular use case is only used for user passwords. If you could find where in the codebase the SimpleNews confirmation links are generated that would be great.

Of course, to get more attention to this issue, one of us will probably have to bump it to 7.x and write a patch. Maybe I'll get around to doing that soon, but I don't know if I'll have time.

I'll investigate and let you know. One of my colleagues (temporarily) solved the problem by upping the max length for url before it gets truncated in the admin settings somewhere (not 100% sure where this setting is). I haven't done any 7.x dev work yet, just spent the last 6 months building a very big 6.x website lol.

Try /admin/settings/filters/1/configure (and repeat for other filters applied to your users). I'm trying it now myself to solve this problem.

kaississieh:

I believe that input filters are only applied to text on the site. I am talking about links that are generated by the user_pass_rehash function & sent out in emails.

Hi,

Has this issue been fixed, I am experiencing the same problems with one-time-login links truncating and not working as intended. i am using Drupal 6.14 (updating to 6.15 tonight). This is a very real problem for password resets. I have removed the one-time-login links from system generated emails for now (as complaints started filtering in from new users trying to register and use the one-time-login-links, which of course keep expiring once clicked even though they misroute the user). I really think this is needing to be addressed at the core level, to minimize the number of characters in system generated passwords to something closer to 10 if possible, so the login links don't break.

Someone mentioned this is more of a preference than a core bug/fix and I am wondering what they mean by preference. Is there a mail configuration setting that I could alter somewhere to impact outgoing messages, so the one-time-login links don't truncate??

right now outgoing mail messages are configured to use plain text format.

I would really appreciate some advice/input/help with this issue as I can't seem to find a way around it and I don't want to have to hack the core user module to fix this unless it is absolutely necessary.

mel

I'm finding this issue on drupal 6.15 - I was using mime mail but with mails as plain text, and the clickable link in gmail was truncated. At the bottom of the email it did display the correct link:

administrator, A request to reset the password for your account has been made
at Your Site. You may now log in to www.mysite.com
[1] by clicking on this link or copying and pasting it in your browser:
http://www.mysite.com/user/reset/1/1265653296/cfc8289eb1e699f94452edbb39...
[2] This is a one-time login, so it can be used only once. It expires after
one day and nothing will happen if it's not used. After logging in, you will
be redirected to http://www.mysite.com/user/1/edit [3] so you can change your
password.

[1] http://www.mysite.com
[2] http://www.mysite.com/user/reset/1/1265653296/cfc8289eb1e699f94452edbb3922dd90

I changed the settings to not send plaintext mail and then the clickable link used the correct url, although it displayed the truncated url:

administrator, A request to reset the password for your account has been made at Your Site. You may now log in to www.mysite.com by clicking on this link or copying and pasting it in your browser: http://www.mysite.com/user/reset/1/1265655171/442cefe18289e18919442a2315... This is a one-time login, so it can be used only once. It expires after one day and nothing will happen if it's not used. After logging in, you will be redirected to http://www.mysite.com/user/1/edit so you can change your password.

subscribing

Unfortunately, I think that in order to get this fixed, we'll have to get it fixed in 7.x (the current development branch) and backported. Does anyone know of a secure way to resolve this issue? My code in #2 should probably work on 7.x also, but I'm not sure if it's secure.

I am running into the same issue, but at the other end: my emails are sent as HTML, so some users receive them correctly.
But some users (for example behind an Exchange server, or using other email providers or cliants) receive a truncated link, or a changed email such as in #11.
For some people, that is too much to handle, and they do not get it.
We need to find a way to make it more user friendly, in particular for average or even low computer proficiency users.

@Alan.Guggenheim:

Exactly. The issue doesn't occur on all mail clients. For example, I don't believe I've ever had problems on Gmail. However, Outlook always truncates.

Perhaps we could make a shorter confirmation link "opt-in" so that people who want the higher security of a longer link could still have that.

Maybe I'll have time to write a 7.x patch soon. I need to learn CVS checkout, the new codebase, etc. first.

Yes, and in my case, the url for the site is already very long, so the hash would have to be about half of what it is today! I don't think there is a big security risk, and we caoul alleviate by controling the number of unsuccessful login from same username in a certain period of time.

The issue of the one time link though is not simple. More and more people are getting their emails on their phones for example, and need to type usernae and password on a computer. I don't think we can avoid sending a temporary password altogether in all cases.

@Alan.Guggenheim:

The temporary password feature is in LoginToboggan, and is unlikely to get into core, I think, since they don't usually like to add features from contrib modules unless they are critical. But you could always advocate for it.

The truncation issue, though, is definitely a bug.

Actually, LoginToboggan has a temporary passord that the user can select for the registration, but I don't think that works for reset password.

You're right; it doesn't. Perhaps we should post an issue in the LoginToboggan queue requesting that there be a temporary password option for reset password.

I have hundreds of users that are being rejected, so i really need a fix.
First I did a temporary fix by changing the outgoing email to:
!username,

A request to reset the password for your account has been made at !site.
Please note that your username is: !username
If you see your username in red, then click on the link below to reset your password and login,
!login_url

If you do not see the username above in red, and if this text is not in blue, then your email is not in html, but has been converted to plain text, and the link below might have been truncated. If you see a [1] close to it, the complete link has been moved to the bottom of this email next to a [1]. Try to click on it, or copy and paste into your browser.

This is a one-time login, so it can be used only once. It expires after one day, but nothing will happen if it's not used. You can request a new password at any time.

If you have any problem, do not hesitate to send an email to: admin@

I also tried to use an

Thanks

Did you see my 6.x workaround in #2?

Yes, and I will try it if nothing better is offered. I have such a long domain name that this might not be always enough, and it for sure has a pretty low entropy.

We could generate them using a TinyURL-like service, perhaps? Or is that a terrible idea?

For a security related link, I would not feel comfortable going through a third party.

Yes, I didn't think that was a good idea - it was suggested in IRC, but probably in jest. If "low entropy" means "insecure," as I assume it does, I don't know of a way to balance that off against the need for shortness.

I'm having tons of people reporting this problem, since emails are always sent in plain-text. The full link is at the end of the email, of course, but the truncated link is the one people are apt to click on.

No patch here, so setting to active.

subscribe

subscribing...

Suppose this would have to be addressed in 8.x now, before being backported. Does anyone have an idea that is both a) practical (solves the problem of the links being too long), and b) still secure? I never bothering rolling a patch for my code from #2 since I think it is probably not secure enough.

interesting topic. any free email clients have this issue that I can test with..

as what I can remember, hotmail, Gmail...are send long reset password URL, so there are broken in the clients too ?

we can do something like:

SUPER LONG URL
http://www.mysite.com/user/reset/1/1265653296/cfc8289eb1e699f94452edbb39...

reset password code
"cfc8289eb1e699f94452edbb3922dd90"

if the URL failed, redirecting to "reset PW code" page

I'm having tons of people reporting this problem, since emails are always sent in plain-text.

Install Mime Mail or HTML Mail. Problem solved.

Yes, but even then, many people only accept the plain-text alternative. Plus those modules are HUGE overkill for solving a simple problem like this. I hate installing either of those modules on sites where I don't need them (especially sites where the only thing email is used for is password recovery and registration).

I would agree with geerlingguy. Some clients can't accept HTML Mail. That is what sparked the OP.

@droplet: I think that would defeat the purpose, since how would we know what password code to report if the URL failed?

One possibility would be to put just the hash somewhere in the email body, so that people could type in the site URL, and add the hash at the end. Not as usable, but better than a broken link.

Of course, the full link should stay in the email as well.

@EvanDonovan,

Your suggestion is totally same to my comment :) But I won't tell users "type in the site URL, and add the hash at the end."

I think we easy to check that is a valid reset code or not. I haven't look into code but I guess the reset code is a fixed-length string. (maybe 43 digit in D7) Even don't check on LENGTH. we can tell users what to do when they are failed.

FULL URL -> CLICK IT -> WRONG RESET CODE -> | TELL THEM WHAT TO DO / SHOW A BOX TO TYPE IN THE CODE | -> BACK TO EMAIL & COPY RESET CODE -> TYPE IN RESET CODE

Now in D7, what we do is show them this message:

Status message
You have tried to use a one-time login link that has expired. Please request a new one using the form below.

we ask them request again, it's why users are failed & failed again...

=======

some suggestion say your can put long URL in this way:
<http://~~~~~~~LONG URL~~~~~~~~~~~>
http://www.ietf.org/rfc/rfc2396.txt

@droplet: Ok, you could offer people a box to type in the reset code. I thought you were saying show them the reset code on the website if it failed.

I think a patch to provide a box for typing the reset code, and to make the email have the reset code by itself as well as part of a link would be a workable solution. Does anyone else agree? I don't have time to write this at the moment, though.

going with #2 for now but would rather not be hacking core... so subscribing

Can someone make a module for Drupal 7 for that problem?

Subscribe

#2 works in Drupal 7. What do we need to do to get this committed as a patch?

-Trevor

This is still a critical problem for plain text mails. We have to get this forward...

Regarding #5-9:
#5, #7, and #8 told me a lot about what the solution was; the details may have changed slightly in the intervening 5 years.

This problem is caused by the Plain Text format's Convert URLs into links filter. The solution, like #7 suggests, is to increase the Maximum Link Text Length in that filter.

This was seen in Drupal 7 as an error with one-time-login links sent to users who'd requested new passwords. We're sending plain-text emails. For whatever reason, Drupal applies the Plain Text filter to the body of the email, whereupon the Convert URLs into links filter truncated the password-reset link. Drupal also adds a footnote with the full-length URL, but of course no one noticed this at the time.

So, go to Home » Administration » Configuration » Content authoring » Text formats
( /admin/config/content/formats/plain_text )
and scroll down to Filter settings at the bottom.

Change Maximum link text length from 72 to 255 or whatever keeps the lasagna flying.

I'm also certain that this affects more than just password resets, so I don't think the right solution is to hack the password hashing. The real solution isn't to simply show long URLs in their full length, either, but you do what you gotta. A better solution would be to allow an alternate-text token to be used in the email's template* and show the full URL in the footnote, as currently done.
* Email templates are listed at the bottom of /admin/config/people/accounts

hth

The OP, just to remind people, was about email clients truncating long links in plain-text emails. I don't know whether clients have changed in the past 7 years, but it might still be an issue. If it is, then just changing your input format to remove URL truncating will not solve the problem.

In reply to #42, changing my maximum link length to 999 at e.g. /admin/config/content/formats/plain_text fixed the issue for me, so thank you for that tip.

I tried changing my maximum link length to 255 / 999, but it is not working for me.
I m still getting urls as plain-text in email. This happens only with outlook.
I am using Drupal-7.34.
Does any one have any another solution to get this issue solved?

I can confirm that this is still an issue, at least in Drupal 7.34. I have also set filter-related settings to a maximum length of 999 characters, and we still have occasional users continuing to face the issue. This is because the problem is not always Drupal shortening the URLs, but the email client and/or email provider doing it on the receiving end.

In our case we have a lot of college students who are customers, and 9 times out of 10 when we receive an email with this problem, it is because they use Outlook or their college-provided webmail service, which itself truncates the URL to a number of characters (as mentioned in the OP). We also see this with some users who have their Gmail settings to only receive the plain-text versions of emails.

A shorter token would be ideal, and I think the best way to implement this is with a new module which utilizes hook_url_outbound_alter() to inspect what's being generated by url() and change it as needed. This would also allow us to do things such as storing the original path in a db table for further security and inspection.

*bump* Still an issue on 8.7.x

Ran into this issue trying to set up (what I thought would be) a simple registration site: 1) user submit registration form, 2) verifies email, 3) sets a password after being directed to user edit page, 4) done.

However, step #4 has an issue: once the user logs in via the one-time-login-link from the email verification, they can save the user edit form without setting a new password. This leads them to reset their password, which leads them to this error (other ways of getting there too).

We use outlook and the password reset link is being truncated. The earlier error of saving without a password needs to be addressed as well.

I noticed how long these urls are in email theming. The way the url's are structured doesn't allow them to wrap.

There are only two comments here since 2014 that state this is a problem on Drupal 8 or later. #53 is a problem with the login process not the login link itself, which is this issue. The last comment states the urls do not wrap, which is not the problem stated in the Issue Summary.

So, let's find out if anyone is still having this problem.

Is anyone experiencing the problem where the login link is truncated in plain text emails? If so, add a comment with details of what is happening nd set the status to 'Active'.

Thanks!

Thanks, @quietone, for our specific case (#41) I can say, that it only affected Drupal 7, like written in #42.

Never experienced this problem in Drupal 8 plus. If no one runs into this in Drupal 8+, I'd suggest setting the version back to 7.x.

@Anybody, thank you.

It has been 5 months and no one has reported having this problem. The last reported case was 9 years ago on Drupal 7. I am not sure if it is still an issue with Drupal 7 but I will change the version.

This is still an issue in Drupal 9. I had a user experience this issue recently using the alpine plaintext client.

Should we really change the version of this issue? I think a separate issue would make more sense, but at least let's add a reminder this also has to be fixed in D7!

In 9.4.x nothing will happen, please check if the issue exists with Drupal 10.1.x. Thanks!

I'm marking this postponed because it's not at all clear what the proposed solution is? I can only imagine that if you use a plain text email client this comes up across many sites as a lot of them send emails with long links.

I've read through the comments but there is no suggested or agreed solution that I can see? I'm also not sure how to reproduce it, could someone with this problem add some more information about it? Is it only in certain email clients?

My version is 10.1, so I'm not sure if it's the same problem as yours.
The email is plain-text, and the length of the link obtained by [user:one-time-login-url] is 119.

Finally got a result:
https://xxxxx-xxx.xxxx.xxxx002.com/xxxxx/en/user/reset/206/1696748244/zs...

In the email it will be displayed as:
https://xxxxx-xxx=
..xxxx.xxxx002.com/xxxxx/en/user/reset/206/1696748244/zsf4sEAXUIZj9qfHBJUwdj=
PfAbed1ZIyL4ipsaP7_Ws

As you can see there are two '.'s in the domain name causing it to become an incorrect and unusable link.
I think this is due to the lineLength control of the Headers in the email, causing line breaks.
If the line break happens to start with '.', then it will produce two '.'

I have used both plain text and HTML based emails across many projects, Drupal versions, and email clients all the way back to D6 and I've never seen this issue.

Considering the disparate reports and lack of detail (e.g steps to reproduce) I'm inclined to close this as won't fix or at least change it to a support request?

If people are still seeing this issue, please at least include the email client you're using. I see 1 year ago in #62 it was reported in alpine plain text (never heard of that) and 4 years ago in Outlook. Does it still happen in Outlook? Is it only certain versions? Certain settings? Etc.

This feels like it could fall into the same category as a bug report that styling is broken on some obscure/ancient browser...

Alpine is apparently still supported by its developer. It's a valid text-only mail client for linux systems. This issue did exist in Alpine last I checked a year ago and was originally reported by a client of mine that uses Alpine exclusively. Anyone interested in fixing the issue could download and install Alpine to try themselves.
https://alpineapp.email/
https://repo.or.cz/alpine.git

That being said, we could say Drupal may not support text-only mail clients.

@joshuasosa thanks for replying. I suppose that the real question is how do you propose to fix it? Would you say the fix is to shorten the URL for all users to accommodate this? That feels like a hard sell.

I'm not sure how to solve, but leo in #66 had a note about headers being the cause. I'm also unsure how to test anymore: testing again on Windows 10 Ubuntu WSL in alpine, my Terminal and PowerShell allow clicking on links in alpine, meaning it seems to work ok. There may be a combination of another version of Linux and mail client where it doesn't work properly. (My client is now retired.)

Perhaps someone that still encounters the issue could provide details about platform and email client used to help replicate for fixing and testing.

Just here to provide some information about my situation, will try to use #42 fix.
Happens to me in gmail when emails go to spam folder.
When email goes to normal gmail inbox then it can be seen that url is truncated but it's clickable because href attribute has full length url - <a href=[full length url]>[truncated url]</a>
The problem or confusion for users is when that email goes to gmail spam folder then (probably for safety reasons) email is converted to plain text and thus users see truncated urls and they might try to copy/paste it and then link is broken. When email is moved to normal inbox then html link attribute is available again and can be clicked and everything works again.
So to lessen confusion for users plain text links should also work when email client decides to display email as plain text for security reasons.

EDIT: Seems to not happen when I deactivate "Mail system" and "Mime mail" modules - Probably this E-mail format in Mime Mail settings is what caused this for me.

This came up again in Bug Smash. The only new report that this is still an issue with (what I believe is) vanilla core is #66 but we still don't have concrete steps to reproduce.

I'm still inclined to close this one as cannot reproduce.

I am similarly inclined too. The steps to reproduce, including which email client is being used, are needed here to do any proper investigation.

I've updated the issue summary with the standard templates, added the possible workarounds etc.

Since we need that information to move forward with this issue, I am keeping the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

It's been another few months without any steps to reproduce so closing this one out.

If you are able to provide steps to reproduce, feel free to re-open this.