Undefined index: PHP_AUTH_PW /wp-includes/user.php on line 469

[MadtownLems]

wp_validate_application_password only checks for the existence of $_SERVER['PHP_AUTH_USER'] before calling wp_authenticate_application_password with both $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'].

In our environment (using Shibboleth-powered Single Sign-on), $_SERVER['PHP_AUTH_USER'] is already set, but $_SERVER['PHP_AUTH_PW'] is not defined.

I believe that this section:

// Check that we're trying to authenticate
if ( ! isset( $_SERVER['PHP_AUTH_USER'] ) ) {
	return $input_user;
}

should likely be extended to confirm the presence of both variables before calling wp_authenticate_application_password.

(Of course, I'm also now worried about what other problems we'll run into using PHP_AUTH_USER the way we are, but that's for another day!)

[TimothyBlynJacobs]

Thanks for the ticket @MadtownLems!

To clarify, are you manually setting the $_SERVER['PHP_AUTH_USER'] variable in your site?

[MadtownLems]

To clarify, are you manually setting the PHP_AUTH_USER variable in your site?

I apologize in advance for not being an expert in this area, and I'll do the best to explain.

Our WordPress installation itself isn't specifically doing anything with PHP_AUTH_USER. Rather, our webserver is a Shibboleth Service Provider and interacts with our University's Identity Provider to authenticate users. (Our WordPress installation then takes that data and uses it to associate the person with a WordPress user account.)

I have confirmed that PHP_AUTH_USER gets set whenever I try to visit a protected directory that is not related to WordPress at all.

I have no idea how common Shibboleth is, so here is a link for reference in case it's helpful:

​https://www.shibboleth.net/index/basic/

Always happy to answer any more questions, help look into this more, or test things!

[TimothyBlynJacobs]

Thanks @MadtownLems! I'm not very familiar with shibboleth either. I'm wondering if we may want to run even if PHP_AUTH_PW isn't set, but set it to an empty string.

But in my testing at least, even if a password is omitted when doing Basic Auth PHP_AUTH_PW is still set, but to an empty string. Does anyone know if that is always the case when a password is omitted? If so, then I would agree we can just also check for PHP_AUTH_PW being set.

[TimothyBlynJacobs]

Chatting with @richard.tape and doing some research it seems expected that shibboleth wouldn't populate PHP_AUTH_PW. I found this semi related issue ​https://github.com/symfony/symfony/issues/17345 and ​https://shibboleth.1660669.n2.nabble.com/Populate-PHP-AUTH-PW-var-td6185938.html

So now the question is just if PHP_AUTH_PW would be omitted by valid usages of Basic auth on some server setups.

[johnbillion]

If this is allowed it ought to be fixed in places where PHP_AUTH_PW is passed through, for example the site health Ajax checks and the plugin and theme editor syntax checks.

[TimothyBlynJacobs]

@johnbillion It looks like the rest of Core is already also looking for PHP_AUTH_PW. So I think @MadtownLems your proposed solution makes sense. Do you want to take a go at making a patch for it?

[MadtownLems]

Gladly. It's been almost a decade since my last actual patch, but I'm not gonna find an easier one to shake the rust off with!

I'll put something together soon.

[MadtownLems]

Patch of user.php that confirms both variables are set before moving forward with application password authentication

[engahmeds3ed]

Simply use one isset with two arguments

Trac ticket: https://core.trac.wordpress.org/ticket/52003

[TimothyBlynJacobs]

In 49919:

App Passwords: Only attempt auth if the username and password are set.

Previously, only the username was checked which caused a PHP warning in some server setups, for instance Shibboleth SSO, where the server only populates the PHP_AUTH_USER field.

Props MadtownLems, johnbillion, richard.tape, engahmeds3ed.
Fixes #52003.

[TimothyBlynJacobs]

Reopening for backport.

[whyisjake]

In 50045:

App Passwords: Only attempt auth if the username and password are set.

Previously, only the username was checked which caused a PHP warning in some server setups, for instance Shibboleth SSO, where the server only populates the PHP_AUTH_USER field.

This brings the changes from [49919] to the 5.6 branch.

Props MadtownLems, johnbillion, richard.tape, engahmeds3ed, TimothyBlynJacobs.

Fixes #52003.