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

WordPress Trac noreply at wordpress.org
Tue May 24 16:05:26 UTC 2016


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

Comment (by ericlewis):

 Replying to [comment:52 jeremyfelt]:
 > The `validate_username` filter is currently only used when checking the
 string against `sanitize_user` to see if it changed. Moving it to its new
 location in `wp_validate_user_login()` gives it more authority and removes
 the direct true/false response it has now. I'd prefer finding a way to
 apply the filter only in the case of the `sanitize_user()` mismatch
 further up.

 `validate_username()` is currently used to check the username when the
 user is created
 [https://github.com/WordPress/WordPress/blob/733ccfe08adf25d3ea86820824c070ebdf405e16
 /wp-admin/includes/user.php#L145-L146 in edit_user()] and
 [https://github.com/WordPress/WordPress/blob/733ccfe08adf25d3ea86820824c070ebdf405e16
 /wp-includes/user.php#L2254-L2255 in register_new_user()], so I don't
 think we should put it behind a `sanitize_user()` mismatch. The
 implementation in attachment:17904.5.diff keeps the boolean validation
 nature of `sanitize_user()`, and if the username is invalid adds an error
 to the `WP_Error`.

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


More information about the wp-trac mailing list