Application Passwords are unusable in combination with password protected /wp-admin

[SeBsZ]

We've been using the Application Passwords for years to allow our REST-API to make use of authentication using basic auth. This worked perfectly fine.

Now, in WordPress 5.6.0 Application Passwords seems to have been merged into the main code, and suddenly we can't create new passwords because basic Auth has been detected in use on the site. The discussion and changeset that caused this are here: #51939

I totally understand that site-wide basic auth using .htaccess clashes with Application Passwords - but we only use .htaccess basic auth protection on the /wp-admin folder. There's absolutely not reason we should be blocked from creating new Application Passwords.

I don't know how you could solve this - either allow us to dismiss the warning and use AP anyway - or you might need another method to only detect conflicting basic auth on the REST API side - which may be impossible to do.

I've set the severity to major because we have upgraded to 5.6 and can now no longer create new authentication tokens for our REST API users.

Many thanks for your help.

[TimothyBlynJacobs]

Thanks for the ticket @SeBsZ. I think for 5.6.1 what we'll probably want to do is extract that into a function in wp-admin/includes/user.php and put a filter on that check. Maybe wp_is_server_compatible_with_app_passwords()? Not sure, would very much like input :)

Would you be interested in putting together a patch for that @SeBsZ?

[archon810]

That'd be a fine solution, or maybe just have it as a UI setting. After all, if we had Application Passwords before, that was our "yes, this is supported and should be on" toggle, but with 5.6, we lost it.

A direct upgrade to 5.6 also broke API authentication for us - it started coming back with 401, but @SeBsZ traced it down to the using_application_passwords key not getting created during the db migration for some reason. Have you had other reports of this?

[archon810]

I just reran the upgrade since we had to downgrade back to 5.5.3, and this time the using_application_passwords key got created correctly. Not sure why it didn't the first time.

[TimothyBlynJacobs]

@archon810 I haven't seen other reports of that issue. It is a fairly straightforward upgrade routine. Were there any associated errors during the first upgrade routine?

[archon810]

No, I don't recall any update issues. The db update screen showed up, I clicked it, it updated very quickly, and it was done.

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

[SeBsZ]

Thanks @TimothyBlynJacobs, this patch/PR looks great. We'll be able to hook into this filter and it'll fix the issue for us. Looking forward to 5.6.1.

[aaroncampbell]

The patch here looks good to me - I think this one is ready to go in.

[TimothyBlynJacobs]

One of the issues here is what we really care about is whether the front-end is protected by Basic Auth, but we are forced to check this in the admin area. So after thinking on this and @ocean90's comment, I tweaked the function to accept a specific context to check for. I think this makes it clear how this function is intended to be used, and its current shortcomings.

I think for 5.7 we could explore making this more robust by doing a loopback request and checking for a WWW-Authenticate header.

What are people's thoughts on this?

[SergeyBiryukov]

Replying to TimothyBlynJacobs:

I think this makes it clear how this function is intended to be used, and its current shortcomings.

The approach in the current PR makes sense to me for 5.6.1. Inaccurate results are not ideal, but it looks like a filter is the most straightforward solution for now.

I think for 5.7 we could explore making this more robust by doing a loopback request and checking for a WWW-Authenticate header.

That would be great :)

[TimothyBlynJacobs]

In 50006:

App Passwords: Extract Basic Auth check into a reusable filterable function.

In [49752] a check was added to prevent creating new Application Passwords if Basic Auth credentials were detected to prevent conflicts. This check takes place in WP-Admin, though a conflict would only arise if Basic Auth was used on the website's front-end.

This commit extracts the Basic Auth check into a reusable function, wp_is_site_protected_by_basic_auth(), which can be adjusted using a filter of the same name. This way, a site that uses Basic Auth to protect WP-Admin can still use the Application Passwords feature.

In the future, instead of requiring the use of a filter, WordPress could make a loopback request and check for a WWW-Authenticate header to make this detection more robust out of the box.

Props SeBsZ, archon810, aaroncampbell, ocean90, SergeyBiryukov, TimothyBlynJacobs.
Fixes #52066.

Merged in ​https://github.com/WordPress/wordpress-develop/commit/ffd7fd81680f0650a80b69533f80d95d18bc49de.

[TimothyBlynJacobs]

Reopening for backport.

[whyisjake]

In 50044:

App Passwords: Extract Basic Auth check into a reusable filterable function.

In [49752] a check was added to prevent creating new Application Passwords if Basic Auth credentials were detected to prevent conflicts. This check takes place in WP-Admin, though a conflict would only arise if Basic Auth was used on the website's front-end.

This commit extracts the Basic Auth check into a reusable function, wp_is_site_protected_by_basic_auth(), which can be adjusted using a filter of the same name. This way, a site that uses Basic Auth to protect WP-Admin can still use the Application Passwords feature.

In the future, instead of requiring the use of a filter, WordPress could make a loopback request and check for a WWW-Authenticate header to make this detection more robust out of the box.

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

Props SeBsZ, archon810, aaroncampbell, ocean90, SergeyBiryukov, TimothyBlynJacobs.

Fixes #52066.

[SergeyBiryukov]

In 50053:

Docs: Update documentation for wp_is_site_protected_by_basic_auth() per the documentation standards.

Follow-up to [49752], [50006].

See #52066.

[SergeyBiryukov]

In 50054:

Docs: Update documentation for wp_is_site_protected_by_basic_auth() per the documentation standards.

Follow-up to [49752], [50006].

Merges [50053] to the 5.6 branch.
See #52066.