WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 7 months ago

#46794 new defect (bug)

wp_authenticate_email_password fails due to incorrect evaluation of $user object

Reported by: Csassaf Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.1
Component: Users Keywords: has-screenshots needs-patch dev-feedback
Focuses: Cc:
PR Number:

Description

While testing an authentication method that uses wp_authenticate where I was passing in a correct email address and password combination that was failing, I traced the code through to the wp_authenticate_email_password method in wp_includes/user.php in wp 5.1.1.

Line 251 executes wp_check_password with $password, $user->user_pass and $user->ID, however $user->user_pass does not exist in $user, rather it exists in $user->data->user_pass.

See attachments for Xdebug code and local variables.

Attachments (1)

wp_authenticate_email_user-bug.png (138.9 KB) - added by Csassaf 7 months ago.
VS Code/Xdebug screenshot of issue

Download all attachments as: .zip

Change History (4)

@Csassaf
7 months ago

VS Code/Xdebug screenshot of issue

#1 @spacedmonkey
7 months ago

I believe this is due to the fact that wp_set_password doesn't call wp_update_user

#2 @davidbaumwald
7 months ago

  • Keywords dev-feedback added
  • Severity changed from blocker to normal

Doing some digging here, I think this is a non-issue. Yes, $user->user_pass is not shown as a property in the class in XDebug, but at runtime, the magic method WP_User->__get aliases all data properties, including user_pass, for easier use.

#3 @Csassaf
7 months ago

@davidbaumwald agreed, however the value of $user->user_pass is the argument being provided to wp_check_password() in wp-includes/pluggable.php, not a value from WP_User->__get, and wp_check_password() only uses the arguments that it is provided

Last edited 7 months ago by Csassaf (previous) (diff)
Note: See TracTickets for help on using tickets.