Make WordPress Core

Opened 11 months ago

Last modified 8 months ago

#58311 new enhancement

Validate Username for not to be a email and strip everything after @

Reported by: oglekler's profile oglekler Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Login and Registration Keywords: 2nd-opinion needs-dev-note
Focuses: Cc:

Description

Right now it is possible to register user and place full email as Username and username is not supposed to be changed after. When site administrator is adding someone manually, it can be done easily as a mistake and reviling author's email for everyone to see and can be picked up from authors archive as well. Display name can be changed after, but it needs to be done manually, by default Username, Nickname and the Display name are equal.

If some people already have @ in their usernames (and I think I've seen that somewhere), the only thing which can be done about this is to filter the Display name before output and strip the @ and everything after.

Change History (9)

This ticket was mentioned in Slack in #core by oglekler. View the logs.


11 months ago

#2 @jujoko7cf
11 months ago

I'm looking at this issue on contributor day WCEU23

This ticket was mentioned in PR #4578 on WordPress/wordpress-develop by @jujoko7cf.


11 months ago
#3

  • Keywords has-patch added

https://core.trac.wordpress.org/ticket/58311

Removing the @ symbol in the sanitize_user function in strict mode and adding a filter for the allowed characters in case someone wants to change this behavior.

This disallows the symbol at user registration so that future usernames cannot be email adresses.

#4 @jujoko7cf
11 months ago

We did not add a new error message if there is an @ in the username so the default message for illegal characters is displayed:
"This username is invalid because it uses illegal characters. Please enter a valid username."

We noticed that this error message does not contain the allowed characters this should be adjusted from accessibility.

#5 @jujoko7cf
11 months ago

  • Keywords needs-testing added

#6 @costdev
11 months ago

  • Keywords needs-unit-tests added

#7 @costdev
11 months ago

  • Keywords 2nd-opinion added

Depending on how this is being used, it may be considered a backward compatibility break if email addresses can't be used as usernames anymore. It may therefore be preferable to keep the @ as an allowed character, but have a filter where someone could provide allowed characters and exclude @ if they wish.

Adding 2nd-opinion to gather some additional thoughts on whether this should be considered a backward compatibility break, and whether that's ok, or if we should let the user decide if they want to change the status quo.

#8 follow-up: @knutsp
11 months ago

My cents.

Since WordPress started to allow login by email, using a shared form and input field, this is the situation:

Both usernames and user emails are unique. But one user account may have the exact same username as an other account's email. So, which account are you trying to log into, which password is to be checked and what user id to be assigned when successful?

When a shared input field is used, allowing user names (user_login) not always being distinguishable from an email, is a bug.

User names are also not allowed to change, by default. Users email may change. Allowing email as user name invites users to create new accounts when they change email, breaking author archives and order history for ecommerce.

Creating new usernames that looks like emails, i.e. contains "@", should not be allowed from next major. Existing user names should not be affected. No BC break, just fixing a bug that allowed something that should never have been allowed, at least not after login by email was introduced.

#9 in reply to: ↑ 8 @rajinsharwar
8 months ago

  • Keywords needs-dev-note added; has-patch needs-testing needs-unit-tests removed

Replying to knutsp:

Both usernames and user emails are unique. But one user account may have the exact same username as an other account's email. So, which account are you trying to log into, which password is to be checked and what user id to be assigned when successful?

I checked on that, and it does seem that the user, with whom the password matches is the one, that it logs with.

What I would suggest is, while creating a new user with an email, it should be checked that if that email is someone's username. The same goes for the username, we should check if that username matches with any user's email. But, we need suggestions about what we should do for existing users who are currently having this edge case.

For me, I don't think using any filters to strip out the username would be a great way to go.

Note: See TracTickets for help on using tickets.