Usernames ending in a period generate invalid reset password links in certain email clients

[paulcline]

Password reset links contain the username appended to the end of the URL. If the user name ends in a period the email client has to decide if the period is part of the URL or part of the punctuation of the sentence. For example:

<​https://some-wordpress-site.com/wp-login.php?action=rp&key=V4LSmgBcwtqvFPEiFt0e&login=p.o.>

Gmail generates a clickable link that stops short of the final period. Outlook successfully links the entire URL.

[paulcline]

Periods are valid in URLs, but we can avoid the issue by forcing "." to encode to "%2E" when generating the link in the email. PHP automatically converts the "%2E" back to "." when it's passed into the receiving side.

[obrienlabs]

It looks like this type of email can be sent out in 2 scenarios that I can find.

1. New user email with a link to access their account
2. Password reset.

I can confirm that both are broken for me in GMail, too. When clicking the link in GMail I get invalid token. I tested with the thick Outlook client and outlook.com webmail and both of those worked fine. Seems isolated to GMail. Given how many people use gmail this seems like a good one to fix.

Your initial patch fixed the Reset Password process with a test user.

Could you update the patch for the new user email process as well?

[daveagp]

It would be great to fix this bug, which I discovered as the source of pain for my users for years (and me, since I usually have to do a manual reset for them).

I see it's been dormant for a while, but I also see the fix. How can I help this fix go in?

On my website we get about one email a month from a person who can't create an account. This turns out to be caused by https://core.trac.wordpress.org/ticket/42957

• you're using gmail
• you try to create an account name ending in a period, e.g. Dave P.
• the email is sent containing ​https://blah...&login=Dave%20P.
• gmail generally assumes links ending in periods have the periods added by humans and thus ignores them
• so clicking on it, you arrive at ​https://blah...&login=Dave%20P and the user's told the link is invalid

Fixes this by encoding the trailing period as an entity.

This is my first submitted pull request to WP, thanks in advance for telling me if any more steps are needed.

Trac ticket: https://core.trac.wordpress.org/ticket/42957

[daveagp]

Diff generated from github pull request

[daveagp]

@spacedmonkey1 Attempting to ping you since I see you listed as a component maintainer on Users and I'm not sure what steps might be needed to get this reviewed

[markparnell]

Moving to 5.8 to see if we can close this out.

[hellofromTonya]

Today is 5.8 Beta 1. Ran out of time for this ticket to land. Punting to 5.9.

[audrasjb]

I committed some changes to the Doc Block in the proposed PR, and I fixed the conflicts against trunk: ​https://github.com/WordPress/wordpress-develop/pull/1095

Supersedes PR #1095 which was based on master instead of trunk. trunk has the polyfill and latest updates.

Trac ticket: https://core.trac.wordpress.org/ticket/42957

Closing as this PR is based on master instead of trunk. PR #1896 supersedes it.

[hellofromTonya]

I'm not sure about the current approach to add a separate function. Rather, I'm wondering why this happens and if there are other ways to resolve it.

With 5.9 Beta 1 tomorrow, punting to 6.0 and assigning to myself to do the further investigation.

[daveagp]

IIRC the problem is in Gmail handling of urls. It assumes that if you end a url in a period, you actually mean the period as the end of a sentence. My hope is to add this compatibility for Gmail which at the same time is not harming any other service. Please let me know if there's anything I can do, because this is a pain for my users and causes toil for me that I would like to eliminate.

[costdev]

Per the discussion on the bug scrub, pinging @hellofromTonya to see if you've had time to do further investigation on a possible alternative approach?

[costdev]

Per the discussion in the bug scrub, I'm moving this to _Future Release_ as it still needs investigation on a possible alternative approach.

As the investigation isn't already scheduled, let's keep this off the 6.1 milestone until it progresses towards a resolution.

[daveagp]

Hi, what investigation is needed exactly? I would love to get this fixed ASAP.

Why is this code needed? Gmail auto-hyperlinking ignores periods at the end of plaintext links.

Why does it do this? My understanding is that it's a combination of two accessibility features:

(1) Gmail automatically turns plaintext links into hyperlinks. So you can click on even plaintext links, instead of copying and pasting.

(2) It assumes that if someone writes a plaintext link with a period at the end, it's meant as punctuation. E.g. "To blog, go to wordpress.com." The implied link is not wordpress.com. but it is wordpress.com instead.

The proposed fix changes the wordpress-generated plaintext link to one which doesn't fall into this accessibility interpretation. Of course, nothing is currently broken for people who copy-and-paste the URL, but this is not what most people do (can confirm as, in my volunteer role for cscircles.cemc.uwaterloo.ca I get lots of support requests from teachers and students who are running into this deficit).

I happen to work at Google (not on gmail) but if that is what is needed to move this forward I can even try to get any specific questions you have answered from folks working on gmail.

Thanks!

[hellofromTonya]

Clearing me as the ticket owner, as I'm no longer am a sponsored contributor. Clearing ownership opens the ticket for someone to step in to shepherd this ticket forward to resolution.

[oglekler]

@hmbashar I don't think that current patch is ready for testing, I assume it needs more work to be done first.

[daveagp]

Hi, I'm the author of the patch and tests but would love to help however I can. I've tested on my own machine the link generation and link functionality. If more details would help or there's other tasks I can contribute to please let me know.

[oglekler]

@daveagp last PR has a comment that isn't addressed. Please check it out.

I also wonder if

$url = str_replace('.', '%2E', $url);

will be more logical.

On my website we get about one email a month from a person who can't create an account. This turns out to be caused by https://core.trac.wordpress.org/ticket/42957

• you're using gmail
• you try to create an account name ending in a period, e.g. Dave P.
• the email is sent containing ​https://blah...&login=Dave%20P.
• gmail generally assumes links ending in periods have the periods added by humans and thus ignores them
• so clicking on it, you arrive at ​https://blah...&login=Dave%20P and the user's told the link is invalid

Fixes this by encoding the trailing period as an entity.

This is my first submitted pull request to WP (technically second but it's a fix to the first), thanks in advance for telling me if any more steps are needed.

[daveagp]

Thank you @oglekler !

Ok, I didn't exactly know the details of comments on the second PR which copied mine but from the right trunk. I've tried again in ​https://github.com/WordPress/wordpress-develop/pull/6834/files and renamed it according to a comment I saw. I didn't get a notice of the comments on the second PR since it wasn't mine but hopefully I'll see any on this 3rd one.

The comments on 2nd PR also say "If this function remains, it should be a core-only private function". I don't know if that is already true or not, but if important, I'd need a hint on what concretely to change, thank you in advance.

I agree that str_replace would work, but given that periods mid-user name are extremely common and unproblematic for all email clients (I've got many user reports from the trailing period but none from any other position), my thinking is not to unnecessarily create mumbo jumbo in their invitation emails.

[nhrrob]

We are very close to RC1.
Hopefully it can make into 6.7

[dmsnell]

Here are a couple of thoughts on this:

It seems like a very specific failure and not entirely a bug in WordPress, as WordPress is properly generating links. It's the email clients that misinterpret them, so this is more like a way for WordPress to interoperate better in the ecosystem. To that end I don't know if it makes a lot of sense to introduce a new unclear abstraction in functions.php. Maybe what would do well here is a very specific targeted fix that doesn't raise other questions.

I also wonder if

$url = str_replace('.', '%2E', $url);

will be more logical.

For example, this will break almost every URL that passes through it, by replacing the actual dots in the host part of the URL with percent-escapes. There are also problems with running URLs through rawurlencode(): for one, it's not safe to run the entire URL through that function; for two, it will double-escape and corrupt anything that was already escaped.

---

So now I wonder if there is a simpler way to address this that resolves the issue without raising framework level questions. In the third patch there are two changes to generated URLs but only one of the URLs has the problem in various email clients. Each URL contains a query arg action=rp

What if instead of all of this, we simply moved the login=" . rawurlencode( $user_login ) . " part to the front and ended each URL with &action=rp? There would be no conflict, the exact issue would be avoided, and the change would require essentially no review because there are no new overarching questions or API design work involved.

-	$message .= network_site_url( "wp-login.php?action=rp&key=$key&login=" . rawurlencode( $user->user_login ), 'login' ) . "\r\n\r\n";
+	$message .= network_site_url( "wp-login.php?login=" . rawurlencode( $user->user_login ) . "&key=$key&action=rp", 'login' ) . "\r\n\r\n";

I've reimplemented using the nice solution from https://core.trac.wordpress.org/ticket/42957#comment:37. Thanks @dmsnell for the review and thoughtful suggestion!

[dmsnell]

@daveagp can you reconfirm the problem and that the latest patch resolves it? I'd love to see the generated URLs used in your test. I think that it's safe to merge after that confirmation because the latest patch involves no framework-level changes and no broader questions: it's simply avoiding the problem altogether.

[daveagp]

Sorry for the delay - I have now confirmed it works end to end. Here is an sanitized example url it generated during account creation:

​https://cscircles.cemc.uwaterloo.ca/dev/wp-login.php?login=testuser.&key=fake&action=rp

Gmail was able to understand it and present it to the user correctly

[dmsnell]

In 58674:

Users: Avoid ambiguous password reset URLs for usernames ending in a period.

When WordPress sends out a password-reset or new-user email, it generates
a link for someone to follow in order to take them to the reset page. If
the user login name ends in a period, however, that generated URL will
end in a period and many email clients will confuse it with a
sentence-ending period instead of being part of the query arguments.

In this patch, the generated URL's query argument are rearranged so that
the link will never end in a period. Alternative ideas were explored to
create a new function to escape URL-ending periods, but this patch resolves
the reported problem without raising any further architectural questions.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/6834
Discussed in https://core.trac.wordpress.org/ticket/42957

Props audrasjb, costdev, daveagp, dmsnell, hellofromTonya, markparnell, mukesh27, nhrrob, obrienlabs, paulcline.
Fixes #42957.

Merged in [58674]
​https://github.com/wordpress/wordpress-develop/commit/82deed39a56f46bccde20724065ef0d50455f3a7