| 3 | | However, I just noticed that `wp_authenticate_username_password` also has checks for the user or their site being marked as spam. Based on how things work today, the spammer would still be able to login using an auth plugin like OpenID, since that happens before the spammer checks. My gut reaction is that the spammer check should not happen inside the `wp_authenticate_username_password` method, since that actually has nothing to do with the original intent of that method... authenticating a user by username and password. Instead, I think it should be its own function that hooks into 'authenticate' much later. |
| | 3 | However, I just noticed that `wp_authenticate_username_password` also has checks for the user or their site being marked as spam. Based on how things work today, the spammer would still be able to login using an auth plugin like OpenID, since that happens before the spammer checks. My gut reaction is that the spammer check should not happen inside the `wp_authenticate_username_password` method, since that actually has nothing to do with the original intent of that method... authenticating a user by username and password. Instead, I think it should be its own function that hooks into 'authenticate' much later. If you're okay with the patch as written, I'll open a separate bug to track this. |