[wp-trac] [WordPress Trac] #19714: plugins which use the 'authenticate' hook unable to return errors
WordPress Trac
noreply at wordpress.org
Sun Jul 28 22:25:34 UTC 2013
#19714: plugins which use the 'authenticate' hook unable to return errors
--------------------------+------------------------------
Reporter: willnorris | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: 3.3
Severity: normal | Resolution:
Keywords: has-patch |
--------------------------+------------------------------
Comment (by willnorris):
Patch updated.
I'm still bailing out of `wp_authenticate_username_password` early if the
passed in `$user` is a `WP_Error`, rather than letting the missing
username and password errors be attached as @nacin suggested above.
Otherwise, that would then require removing them from the error object
later, and the code started getting really ugly. Besides, I can't think
of a use case where a plugin would have already returned an auth error,
and we would still care about whether a username and password were
provided. If the username or password are relevant to the plugin, then
its error message should mention that.
I've also made two additional changes:
- as discussed previously, the spam check has been moved to it's own
function and added as a late hook (priority 99) on the `authenticate`
filter. This will now block spam accounts regardless of what
authentication method they used.
- default authentication filters have been moved out to `default-
filters.php` where they really belong
--
Ticket URL: <http://core.trac.wordpress.org/ticket/19714#comment:12>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list