#6675 closed defect (bug) (fixed)
wp-login.php refactoring makes it difficult to write an authentication plugin
Reported by: | dwc | Owned by: | ryan |
---|---|---|---|
Milestone: | 2.5.1 | Priority: | normal |
Severity: | normal | Version: | 2.5 |
Component: | General | Keywords: | |
Focuses: | Cc: |
Description
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.
Move wp_authenticate action up