[wp-trac] [WordPress Trac] #5918: Allow non-ASCII usernames

[WordPress Trac]

#5918: Allow non-ASCII usernames
-------------------------------------+-----------------------------
 Reporter:  marshosh                 |       Owner:  (none)
     Type:  feature request          |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Charset                  |     Version:  2.3.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-refresh  |     Focuses:
-------------------------------------+-----------------------------
Changes (by dmsnell):

 * type:  enhancement => feature request
 * component:  Users => Charset


Old description:

> Hello ...
> I can't make New username with arabic characters ...
>
> who i can apply an arabic characters in usernams ?
>
> Thank you ...

New description:

 WordPress currently transforms usernames and potential usernames into a
 restricted set of ASCII characters. It attempts to remove HTML,
 diacritics, and transform other characters to ASCII equivalents, stripping
 away anything that remains.

 This prevents storing usernames that correspond to someone’s name or
 chosen identify, if that name falls outside the restricted range. For
 example, the username `北斎` is unusable because `sanitize_user( '北斎',
 true )` returns the empty string.

 WordPress should relax its restrictions on usernames to be more inclusive
 and permit locale-specific sites and users to express themselves as they
 are, not having to make concessions for latin-based technology.

 == Complications

 - Not all restrictions should be removed, but it would be important to
 double-down on the original intent of those  filters; notably, to limit
 confusable characters such as non-printable and non-visible characters.
 Unicode defines considerably more complicated text rules, so an update to
 the system should improve the Unicode compliance surrounding these issues.
 - Given the higher probability of multiple representations for non-ASCII
 usernames, it would be important to normalize all inputs using an appriate
 algorithm, such as NKFD.
 - Existing code and plugins are going to assume ASCII-only usernames and
 unlocking more complete naming should not introduce any more backwards
 compatibility breaks than are absolutely necessary.
 - Some installations will be running on non-UTF-8 database tables which
 cannot represent all possible Unicode-based usernames. For these
 installations, it must be clear that extended username support is
 unavailable.

 == Help

 Unicode provides ample guidance here which can help WordPress to:
  - avoid known security issues
  - implement these behaviors in harmony with expectations from other
 software
  - how to best display these characters in interfaces

 == Warnings

  - [https://unicode.org/faq/security Unicode Security FAQ] and
 [https://www.unicode.org/reports/tr36/tr36-7.html Security Considerations
 Technical Report]
  - [https://engineering.atspotify.com/2013/6/creative-usernames Spotify
 shared about some security issues] with Unicode usernames.

 == Related

 - #62948 Non-ASCII slugs need comprehensive transformation and inspection
 as well.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/5918#comment:35>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform