Opened 4 years ago
Closed 4 years ago
#52642 closed defect (bug) (fixed)
Site Health resets htpasswd authorization on scroll
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 5.8 | Priority: | normal |
Severity: | normal | Version: | 5.6 |
Component: | Site Health | Keywords: | good-first-bug has-patch |
Focuses: | rest-api | Cc: |
Description
Website is behind HTPasswd Basic Auth. Sign in.
Sign in to wordpress admin.
Navigate to Site Health tools page
Scroll down, and wait a bit.
HTPasswd asks for re-auth. Sign in again.
scroll down and wait a bit. Lather rinse repeat.
problem tested and confirmed on three separate sites after initial discovery.
Attachments (1)
Change History (16)
#1
@
4 years ago
- Focuses rest-api added
- Milestone changed from Awaiting Review to Future Release
- Version changed from 5.6.2 to 5.6
#2
@
4 years ago
I agree @TimothyBlynJacobs, the question is if we should just remove the check altogether, like the HTTPS check if on a local setup, or let the test run, but add the check there to return a success state without doing the Authorization header check call?
I tend to lean towards the latter, that way it's possible for a user to look at the passed tests section and see it reliably.
#3
@
4 years ago
- Keywords needs-patch good-first-bug added
- Milestone changed from Future Release to 5.8
Good call, I think you're right and we should skip performing the check but still return a valid result, maybe including some additional text that it wasn't directly performed.
#4
@
4 years ago
Having looked at how the test is set up, I actually will re-evaluate my previous suggestion, since the test sets headers to run at all, this will lead to more confusing logic than just outright skipping that test if not applicable.
With that knowledge in hand, we should instead do the same as with the REST API availability check, and only conditionally add it if wp_is_site_protected_by_basic_auth
returns false
This ticket was mentioned in Slack in #core by clorith. View the logs.
4 years ago
This ticket was mentioned in PR #1320 on WordPress/wordpress-develop by costdev.
4 years ago
#6
- Keywords has-patch added; needs-patch removed
Add Authorization header test only when wp_is_site_protected_by_basic_auth
returns false.
Trac ticket: https://core.trac.wordpress.org/ticket/52642
4 years ago
#7
Thank you for the patch @costdev, this looks spot on for what is needed here!
I can't seem to find an associated WordPress.org user for you, would you mind leaving a comment on the relevant trac ticket as well, for the sake of us keeping tabs on who has worked on the ticket? (you can also link your GitHub account with your WordPress.org one from https://profiles.wordpress.org/me)
#9
in reply to:
↑ 7
@
4 years ago
Hi @Clorith, coming out of the shadows and leaving a comment as requested!
Also linked my GitHub account with my WordPress.org one - thanks for the advice!
#11
@
4 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
wp_is_site_protected_by_basic_auth()
is defined in wp-includes/load.php
and is used without a function_exists()
check in:
Why do we check if it exists here?
Same goes for rest_url()
, we use it without a function_exists()
check right above in the same method, and then for some reason check if it exists :)
It seems to me that these two checks are redundant, see 52642.diff.
#12
@
4 years ago
Good point @SergeyBiryukov and well spotted! The diff you attached looks good. How do we proceed?
#13
@
4 years ago
You're quire right @SergeyBiryukov, the rest_url
check is a remnant of the Health Check plugin (which did not have REST endpoints back then) I believe, so contextually in that regard it made sense to have the same check around the wp_is_site_protected_by_basic_auth
.
We should be able to safely just remove both those function_exists()
checks here, as you mentioned.
Thanks for the ticket @WebDragon!
My inclination is that this is caused by the Site Health test that checks for whether the
Authorization
header is properly making it's way back to WordPress.@clorith perhaps we should skip that test if
wp_is_site_protected_by_basic_auth
returns true?