[wp-trac] [WordPress Trac] #8938: Use new filter for extending WordPress authentication

[WordPress Trac]

#8938: Use new filter for extending WordPress authentication
--------------------------+-------------------------------------------------
 Reporter:  wnorris       |       Owner:  ryan     
     Type:  defect (bug)  |      Status:  new      
 Priority:  normal        |   Milestone:  2.8      
Component:  Security      |     Version:           
 Severity:  normal        |    Keywords:  has-patch
--------------------------+-------------------------------------------------
 One of the key problems with WordPress authentication as it exists today
 is that it is very username/password centric.    The wp_authenticate()
 function immediately fails if either of those two things are missing.
 This becomes particularly problematic when using non-traditional
 authentication methods like OpenID and OAuth.  While wp_authenticate() can
 be replaced by a plugin, this causes other problems described in ticket
 #8833.

 The best compromise (proposed by Peter Westwood) is to use a new filter
 for authentication.  wp_authenticate() would be responsible for basic
 sanitizing of username and password, and then call the filter.  Two
 implementations of this filter would be added in core:

  * wp_authenticate_username_password - does normal username/password
 authentication against the WP user table

  * wp_authenticate_cookie - attempts authentication using the auth cookie.
 By default, this would only be used when doing traditional login (via wp-
 login.php).

 Plugins can simply add a new function which uses this filter and
 authenticate the user by whatever means they choose.  Both of the above
 functions will immediately return if they see that the user has already
 been authenticated.


 A few notes on backward compatibility...  I propose leaving
 wp_authenticate in pluggable.php for the time being so plugins that
 replace it don't break.  I would however like to deprecate that in favor
 of the new authenticate filter, and eventually move wp_authenticate to
 user.php.  I've left the wp_authenticate action in wp_signon() for the
 time being, but I think it can also be deprecated.  I'm currently in the
 process of doing a very thorough analysis of all plugins in the WP.org
 directory to see which ones are even touching the authentication code.
 I've still got a bit more to do, but I think we're only talking about
 20-30 plugins max.


 There are a couple of small hacks in the included patch:

  * one small one that I'm not too worried about that prevents the "empty
 username" error from displaying when you first load wp-login.php

  * a bit uglier one used to pass the $secure_cookie boolean from wp_signon
 to wp_authenticate_cookie.  Ugly just in the fact that it throws it into a
 global.  Since $secure_cookie is actually set in wp-login.php in global
 scope, I think we might just be able to use that, and not worry about
 passing it in to wp_signon as a parameter.

 I'm very open to changes to what I've got... I'm less concerned with how
 we actually achieve this, so long as we get the desired result.

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