[wp-trac] [WordPress Trac] #19714: plugins which use the 'authenticate' hook unable to return errors

WordPress Trac wp-trac at lists.automattic.com
Tue Jan 3 00:43:14 UTC 2012


#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:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------------------
Changes (by willnorris):

 * keywords:   => has-patch


Comment:

 The way the 'authenticate' hook is designed, it's up to each function
 which implements the hook to look at the passed in user value and decide
 what to do with it.  WordPress core has two functions which implement this
 hook, `wp_authenticate_username_password` and `wp_authenticate_cookie`.
 Both of these will immediately return if the passed in user is a `WP_User`
 object, but they don't do anything special if it's a `WP_Error` object.
 In some cases, the error will get passed through untouched, but in other
 cases it will get overwritten, as described above.

 We have to be careful about returning immediately if a `WP_Error` object
 is present, however.  The authentication system currently allows for
 failover.  Even though one authentication method may have failed, there's
 nothing to say that a later one might not still succeed and successfully
 authenticate the user  (this is especially true of
 `wp_authenticate_cookie` which pretty much exclusively relies on this
 approach).

 The provided patch modifies only the `wp_authenticate_username_password`
 function to check, at the point where it would have otherwise overwritten
 an existing `WP_Error`, and return the passed in `WP_Error` if it exists.
 The rationale here being that if a WP_Error is already present, it must
 have been set by a plugin trying to handle authentication, and should
 therefore trump the "no username or password" error.  If a plugin actually
 does care about the absence of the username or password, it will be up to
 them to add that error as well.  This also still allows
 `wp_authenticate_username_password` to attempt to authenticate the user
 using the username and password if present.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19714#comment:2>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list