[wp-trac] [WordPress Trac] #6675: wp-login.php refactoring makes it difficult to write an authentication plugin

[WordPress Trac]

#6675: wp-login.php refactoring makes it difficult to write an authentication
plugin
---------------------+------------------------------------------------------
 Reporter:  dwc      |       Owner:  anonymous
     Type:  defect   |      Status:  new      
 Priority:  normal   |   Milestone:  2.5.1    
Component:  General  |     Version:           
 Severity:  normal   |    Keywords:           
---------------------+------------------------------------------------------
 The refactoring of wp-login.php done for 2.5 for bug #5405 changed the
 behavior of the {{{wp_authenticate}}} plugin hook in a subtle but
 important way.

 Previously (see, for example,
 http://trac.wordpress.org/browser/branches/2.3/wp-login.php#L287) the
 {{{wp_authenticate}}} hook ran by default when wp-login.php is accessed.
 It ran even in cases where the username or password field is blank.

 In 2.5, the "silent" default case is to return a {{{WP_Error}}} object
 when the credentials are blank before {{{wp_authenticate}}} runs.

 Plugins that wish to use the WordPress user store but rely on an external
 authentication mechanism (e.g. http-authentication) have little way of
 doing so now. They can plug into {{{wp_validate_auth_cookie}}}, but that's
 not as clean a solution.

 If possible, could the previous behavior of the {{{wp_authenticate}}} hook
 be restored?

 Alternatively, could another hook be added to restore this behavior?  For
 example, a {{{wp_signon}}} hook could be added above the cookie check in
 {{{wp-includes/user.php}}} and authentication plugins could set the cookie
 themselves on successful authentication.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/6675>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software