WordPress.org

Make WordPress Core

Opened 8 months ago

Closed 6 months ago

Last modified 6 months ago

#52066 closed defect (bug) (fixed)

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

Reported by: SeBsZ Owned by: TimothyBlynJacobs
Milestone: 5.6.1 Priority: normal
Severity: major Version: 5.6
Component: Application Passwords Keywords: has-patch commit fixed-major
Focuses: Cc:

Description

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.

Change History (17)

#1 @TimothyBlynJacobs
8 months ago

  • Milestone changed from Awaiting Review to 5.6.1

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?

#2 @archon810
8 months ago

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?

#3 @archon810
8 months ago

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.

#4 @TimothyBlynJacobs
8 months ago

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

#5 @archon810
8 months ago

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.

This ticket was mentioned in PR #848 on WordPress/wordpress-develop by TimothyBJacobs.


7 months ago

  • Keywords has-patch added

This ticket was mentioned in Slack in #core-passwords by timothybjacobs. View the logs.


7 months ago

#8 @SeBsZ
7 months ago

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.

#9 @aaroncampbell
7 months ago

  • Keywords commit added

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

#10 follow-up: @TimothyBlynJacobs
7 months ago

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?

#11 in reply to: ↑ 10 @SergeyBiryukov
6 months ago

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

#12 @TimothyBlynJacobs
6 months ago

  • Owner set to TimothyBlynJacobs
  • Resolution set to fixed
  • Status changed from new to closed

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.

#14 @TimothyBlynJacobs
6 months ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for backport.

#15 @whyisjake
6 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

#16 @SergeyBiryukov
6 months ago

In 50053:

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

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

See #52066.

#17 @SergeyBiryukov
6 months ago

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.

Note: See TracTickets for help on using tickets.