Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | user system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
This might actually be a feature request.
When a user registers, they get an email with a "one-time login" link, which looks something like this:
http://www.domain.tld/user/reset/3192/1196570478/da5ed50dc3af3b685fede105dedbb02fThat URI (not counting the domain name and protocol) is like 61 characters. Most email clients will truncate long strings in plain-text emails. Not sure if its exactly the same in every client, but seems to be somewhere between 76 and 80 characters in length. This truncation breaks the link every time.
My suggestion is to provide links that are formatted more like TinyURLs, using a shorter hash so the URI is not so long. Could we keep it under 10 characters, maybe? If limited number of possibilities with a shorter hash is an issue, maybe implement a feature that expires these links fairly quickly (e.g. 24 hours)?
Anyway, nothing major but I think it should be considered.
For now, I'm just removing the "one-time login" links from my registration email template completely.
Comments
#1
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.
#2
In order to fix the issue on the password reset emails, I used the following code in user.module:
<?phpfunction 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.
#3
Changing to "needs work".
#4
More specific title.
#5
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.
#6
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.
#7
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.
#8
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.
#9
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.
#10
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
#11
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.#12
subscribing
#13
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.
#14
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.
#15
@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.
#16
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.
#17
@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.
#18
Actually, LoginToboggan has a temporary passord that the user can select for the registration, but I don't think that works for reset password.
#19
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.
#20
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
#21
Did you see my 6.x workaround in #2?
#22
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.
#23
We could generate them using a TinyURL-like service, perhaps? Or is that a terrible idea?
#24
For a security related link, I would not feel comfortable going through a third party.
#25
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.
#26
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.
#27
subscribe
#28
subscribing...
#29
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.
#30
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
#31
Install Mime Mail or HTML Mail. Problem solved.
#32
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).
#33
I would agree with geerlingguy. Some clients can't accept HTML Mail. That is what sparked the OP.
#34
@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.
#35
@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:
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
#36
@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.
#37
going with #2 for now but would rather not be hacking core... so subscribing