WordPress.org

Making WordPress.org

Opened 4 years ago

Last modified 10 months ago

#433 new defect

Block spaces and special characters in login names

Reported by: nacin Owned by:
Milestone: Priority: normal
Component: Login & Authentication Keywords:
Cc:

Description

We blocked @ symbols in WordPress.org user logins a while ago. We should prevent spaces, too. It causes all sorts of messes.

It's fine if a login has uppercase characters, but that should be the only differentiation between that and a user_nicename. If when sanitizing it to a user_nicename, it's not strcasecmp() equal, we should reject it as already chosen.

This is going to block periods in usernames too, which I am fine with. Unless we wanted to allow periods in user nicenames on WordPress.org, but we don't want two users with the same name, just one with a period and one with a hyphen. I presume.

This should include blocking the following situation:

  • Someone registered "example@user", ends up with example-user as a nicename. (This should be blocked in the future.)
  • Someone else registers "example-user". This login is not taken, and it cleanly sanitizes to "example-user". However, with that nicename already taken, they end up as "example-user1" (or -1, I don't remember). This should be blocked as it is incredibly confusing.

Basically: Logins and nicenames should be interchangeable on WP.org.

Change History (4)

#1 in reply to: ↑ description @DrewAPicture
4 years ago

Replying to nacin:

This is going to block periods in usernames too, which I am fine with. Unless we wanted to allow periods in user nicenames on WordPress.org, but we don't want two users with the same name, just one with a period and one with a hyphen. I presume.

+1 for blocking periods too.

We had someone a couple of weeks ago whose plugins weren't lining up with his profile because he had periods in his name. The profiles slug didn't have the periods but his nicename did, and adding the periods to his name in the plugin contributors list fixed the problem, IIRC.

#2 @Otto42
4 years ago

I'm okay with blocking any odd characters in login names going forward. Doesn't fix the already created usernames though.

Reverse this, let's do it as a character whitelist instead. Is there any reason to allow a username to contain anything outside of 0-9, a-z, A-Z, and underscore? Maybe hyphen too.

#3 @kpdesign
4 years ago

I have no issue with either removing the @ and period, or with whitelisting characters (+1 to hypen) for future registered accounts.

However, there is an issue with the profiles of users who have already registered using their email address.

Their login username is name@domain.com, but their username is displayed as namedomaincom, both on their profile, and in the url to their profile.

The issue comes into play when they create Trac tickets. In the ticket description, their profile image does not display, and clicking their username shows no tickets with them as a reporter. You can search for their username in Trac, and tickets and changesets with that username will display.

In the ticket comments, their username displays as with the beginning of the email address they registered with, and clicking on it takes you to the main wordpress.org page, not their profile.

None of their Trac activity is being connected to their .org profile. Forum posts and posts/comments on the Make sites show up, but nothing from either Core Trac or Meta Trac.

I realize this is probably a known issue, but it would be nice to come up with a solution for existing user accounts in this situation. As more and more users begin to contribute to the project, it's important that their Trac contributions show up in their profiles.

Ideas?

#4 @SergeyBiryukov
10 months ago

  • Component changed from Support Forums to Login & Authentication
Note: See TracTickets for help on using tickets.