Usernames with "@" char are assumed email addresses, causing incorrect look-up in several places

[johnjamesjacoby]

Problem

Usernames containing the "@" character are mistakenly assumed to be email addresses when:

• wp-login.php - Resetting passwords
• /wp-admin/user-new.php - Adding an existing user to a site, in multisite
• /wp-includes/user.php - Searching for a user

---

Duplicate

• Create a user with the login "@testing"
• Verify the account, etc...

Bug in Search

• Visit: wp-admin/network/users.php - attempt to search for: "@testing"
• Result: no users found
• What should happen: find the user

Bug in Add New

• Visit: wp-admin/wp-admin/user-new.php - attempt to add: "@testing"
• Result: no users found
• What should happen: add the user

Bug in Reset Password

• Visit: wp-login.php - attempt to reset password for: "@testing"
• Result: retrieve_password() accidentally succeeds, because strpos() check returns 0, which is the correct position of the "@" character. If the username was "testing@" this test would fail

---

Solution

The attached patch fixes these bugs by using is_email() instead of an strpos() for an @ character.

Reminder that as it stands now, users with "@" in their logins:

• Cannot reset their passwords (unless @ is the first char).
• Cannot be added to existing sites.
• Cannot be found in network user searches.

Whether or not user_login should be allowed to have "@" at all is debatable.

Sad to see this get punted to Awaiting Review. It's an easy win, and fixes several similar, existing, user-facing issues with only 3 lines changed.

If it's not a regression from 3.4, it's not that urgent.

Some of the above descriptions need to be qualified with the option of simply using e-mail addresses instead of usernames. It sounds like the features are broken, but not unusable.

I encourage setting a 3.6 milestone.

Replying to scribu:

If it's not a regression from 3.4, it's not that urgent.

All of these bugs are critical to actual users of the software.Replying to miqrogroove:

Some of the above descriptions need to be qualified with the option of simply using e-mail addresses instead of usernames.

Painting the house doesn't fix the holes.

This probably puts too much faith in is_email(), which has its problems. Maybe look for @ in a position other than 0?

Or fix is_email(). If you need a solution for that, I know Google offers a free one that might be GPL compatible.

#17491 for is_email().

It is possible to use a valid email address as a username in single site. Which is more common, a non-email username with @ or an email username?

Replying to ryan:

It is possible to use a valid email address as a username in single site.

I have a hunch LDAP plugins support and/or enable this.

Which is more common, a non-email username with @ or an email username?

I have no stats, but seems moot since we've allowed users with @'s for this long.

Replying to johnjamesjacoby:

Replying to ryan:

It is possible to use a valid email address as a username in single site.

I have a hunch LDAP plugins support and/or enable this.

You're definitely correct on that. I've experienced this issue when working with LDAP integration and it required workarounds (basically, replacing @ with another character when syncing from LDAP).