WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 2 years ago

#32508 new enhancement

Action Hooks for empty username and empty password

Reported by: jwarren Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.3
Component: Login and Registration Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (4)

pluggable.diff (1.3 KB) - added by jwarren 2 years ago.
Patch to add wp_login_failed_empty_username and wp_login_failed_empty_password hooks
testloginhooks.php (622 bytes) - added by jwarren 2 years ago.
Very quick and dirty plugin to test previously mentioned patch
32508.2.diff (799 bytes) - added by MikeHansenMe 2 years ago.
32508.3.patch (1.3 KB) - added by jwarren 2 years ago.
Update of original patch to add Wordpress 4.4 as a target

Download all attachments as: .zip

Change History (14)

@jwarren
2 years ago

Patch to add wp_login_failed_empty_username and wp_login_failed_empty_password hooks

@jwarren
2 years ago

Very quick and dirty plugin to test previously mentioned patch

@MikeHansenMe
2 years ago

#1 follow-up: @MikeHansenMe
2 years ago

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.

#2 in reply to: ↑ 1 @jwarren
2 years ago

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.

#3 @MikeHansenMe
2 years ago

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

This ticket was mentioned in Slack in #core by jwarren. View the logs.


2 years ago

#5 @MikeHansenMe
2 years ago

  • Keywords has-patch added

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.

#6 @jwarren
2 years ago

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
2 years ago

Update of original patch to add Wordpress 4.4 as a target

This ticket was mentioned in Slack in #core by jwarren. View the logs.


2 years ago

#8 @DrewAPicture
2 years ago

  • Milestone changed from Awaiting Review to Future Release

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 :-)

#9 @DrewAPicture
2 years ago

  • Component changed from Plugins to Login and Registration

#10 @jwarren
2 years ago

@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.

Note: See TracTickets for help on using tickets.