#6675 closed defect (bug) (fixed)
wp-login.php refactoring makes it difficult to write an authentication plugin
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| 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