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

[WordPress Trac]

#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     |
--------------------------+------------------------------

Comment (by nacin):

 I am trying to think about what problems the patch could introduce, and
 whether we should be concerned. I don't think we should, and I think I
 like the patch. As long as $user is already a WP_Error object, then
 clearly a plugin has stepped in, and the login won't be successful.

 The other thing I've thought about is allowing add() to run on the
 existing WP_Error object, thus creating an object with at least three
 error codes, and then tweaking it so empty_username and empty_password is
 still filtered out. But the end result is the same, AFAICT.

 I agree that wp_authenticate_username_password() is being abused with the
 spam checks. In MU, it did exist as a separate function hooked into
 wp_authenticate_user. That was merged in with [12879]. The main reason for
 why that occurred was to clean up the MU codebase, but I think ryan would
 support bringing that back out. The wp_authenticate_user hook does seem
 better than `authenticate` for this, though, so I'm a bit torn as to the
 specifics of how we'd handle it.

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