Action Hooks for empty username and empty password

[jwarren]

While you could previously fire an action on wp_login_failed, there were no hooks for an empty username or an empty password. This patch adds wp_login_failed_empty_username and wp_login_failed_empty_password.

wp_login_failed_empty_username passes no arguments.

Similar to wp_login_failed, wp_login_failed_empty_password will pass the entered username.

[jwarren]

Patch to add wp_login_failed_empty_username and wp_login_failed_empty_password hooks

[jwarren]

Very quick and dirty plugin to test previously mentioned patch

[MikeHansenMe]

Instead of adding new hooks is there a reason we exclude those from triggering 'wp_login_failed'? If not we could just pass the additional param into that hook. 32508.2.diff​ is an example and still needs some docs.

[jwarren]

Replying to MikeHansenMe:

Instead of adding new hooks is there a reason we exclude those from triggering 'wp_login_failed'? If not we could just pass the additional param into that hook. 32508.2.diff​ is an example and still needs some docs.

That was actually my initial idea and would definitely be a cleaner option. But I'm concerned about breaking current implementations. If people don't expect their action to fire on wp_login_failed then it could go awry. We also don't have a $username to pass if we're failing due to empty_username. We could end up with white screen of death PHP errors in code that expects it.

[MikeHansenMe]

$username will be set it will just be an empty string.

[MikeHansenMe]

I looked into this a bit more and it seems the code that prevents 'wp_login_failed' was added intentionally.
​https://github.com/WordPress/WordPress/commit/3f22da5123f214ddf4ca9fc73b99cdcc5474269e

Prior to that commit it did trigger on all failures. I asked Ryan about it and he said he thought it was to differentiate between authentication errors and user input errors.

I think by passing in the error code we are still covering that however there is the concern that it is a change in behavior. It was also a change in behavior when that commit was made.

[jwarren]

I did a relatively brief audit of some of the most recently updated plugins which use wp_login_failed: ​https://docs.google.com/spreadsheets/d/1Dc0uCGBjmsIFR5II_E3MzSqdL8q6twiv5GLXJeA-vMA/edit?usp=sharing

It seems that it's used by a lot of logging plugins. Firing wp_login_failed more frequently would change the intended behaviour of how these currently log. Only one would actually break. I don't think it'd be a big change to get them working as intended.

I personally vote for using my original patch to add additional hooks. This will keep current code working as intended and add additional options for expansion if needed.

[jwarren]

Update of original patch to add Wordpress 4.4 as a target

[DrewAPicture]

I think @ryan made the right decision keeping authentication errors separate from user input errors.

@jwarren Can you explain a little more about what your use-case is? We could pass $user to the existing hook, though that might be kind of a round-about way of accomplishing the same goal.

Probably not happening for 4.4, however, beta 1 is today :-)

[jwarren]

@DrewAPicture: Wow, didn't realise 4.4 was so immediate. Good stuff. Well, maybe for 4.5.

Use cases range from simply logging, to providing contextual help, to complex integrations with things that I haven't thought of.

The context of my original submission is that a member of a local PHP group had to do a very complex workaround because he couldn't respond to an empty password field.