[wp-trac] [WordPress Trac] #17904: Multisite has more restrictions on user login character set

WordPress Trac noreply at wordpress.org
Mon Mar 13 20:04:18 UTC 2017


#17904: Multisite has more restrictions on user login character set
-------------------------------------------------+-------------------------
 Reporter:  duck_                                |       Owner:  jeremyfelt
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
Component:  Login and Registration               |  Release
 Severity:  normal                               |     Version:  3.0
 Keywords:  has-patch has-unit-tests 2nd-        |  Resolution:
  opinion needs-refresh                          |     Focuses:  multisite
-------------------------------------------------+-------------------------

Comment (by flixos90):

 @johnjamesjacoby and I had a chat on the behavior of username validation
 (and a tiny bit of email validation) in today's bug scrub (see
 https://wordpress.slack.com/archives/core-multisite/p1489430014794142).
 Here's a summary of what we agreed on:

 Functions for username validation:

 1. `validate_username()`: Will be modified to accept a second parameter
 `$wp_error = false` to make the function return error objects instead of
 false. If `is_multisite()`, the function will include the restrictions for
 multisite (illegal names, minimum and maximum length, illegal logins, all
 numeric).
 2. `username_exists()`: In addition for what this function currently does,
 it can accept a second parameter `$check_reserved = true`. If that
 parameter is true (default), the function also calls
 `is_username_reserved()` (see below).
 3. `is_username_reserved()`: New method that performs the `wp_signups`
 query for existing username that currently happens in
 `wpmu_validate_user_signup()`. Returns true/false.
 4. `wp_validate_user_login()`: New method that acts as a wrapper calling
 `validate_username()`, `username_exists()` with second parameter false and
 `is_username_reserved()`. Returns true/WP_Error.

 The `$check_reserved = true` parameter of `username_exists()` makes sense
 so that by default the check is enforced, but for more granular checking
 by calling the functions manually it can be disabled (see
 `wp_validate_user_login()` that calls them separately to provide distinct
 error messages). This part was not discussed in the chat, but I figured it
 would make sense. Correct me if there are concerns with that. :)

 On a side note, once we get to a patch and closer to a commit here, we can
 open a ticket to perform equivalent changes for email validation.

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


More information about the wp-trac mailing list