wp-login.php refactoring makes it difficult to write an authentication plugin

[dwc]

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.

[ryan]

Move wp_authenticate action up

[ryan]

I think wp_authenticate is misplaced. Moving it up before we check the credentials seems like it would fix the problem.

[dwc]

Yeah, moving wp_authenticate fixes the problem. Thanks!

[ryan]

(In [7691]) Relocate wp_authenticate action to fix back compat and make it more useful. fixes #6675 for 2.5

[ryan]

(In [7692]) Relocate wp_authenticate action to fix back compat and make it more useful. fixes #6675 for trunk