[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