[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