Make WordPress Core

Opened 5 years ago

Closed 2 years ago

Last modified 2 years ago

#47245 closed defect (bug) (worksforme)

Site Health Check: Fails for sites with basic auth and php-fpm

Reported by: stephankn's profile stephankn Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.2
Component: Site Health Keywords:
Focuses: Cc:

Description

Situation is PHP running as CGI (for HTTP/2) and admin interface is protected by basic auth.

Authentication is not possible, as the password is not available in the environment:

https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-site-health-auto-updates.php?rev=45275#L100

the reported conclusion "A plugin has prevented updates by disabling wp_version_check()" is wrong.

Code should check at least AUTH_TYPE for "Basic" or GATEWAY_INTERFACE for "CGI/1.1" to output a proper message. Providing a link to the site-check URL with the instruction to click ans look for the result "yes" in the browser would have also helped.

maybe this check could be done on client-side by javascript in the browser?

Change History (6)

#1 @SergeyBiryukov
5 years ago

  • Component changed from General to Administration
  • Keywords site-health added

#2 @desrosj
5 years ago

  • Component changed from Administration to Site Health

Moving Site Health tickets into their lovely new home, the Site Health component.

#3 @Clorith
5 years ago

Hiya, welcome to WordPress trac, and my apologies for the delayed response.

We could absolutely improve the text used for that test, to make it a bit more descriptive, and not directly blame plugins like it currently does (there are many reasons it could fail, as you've mentioned).

I think that this specific scenario is a bit of an edge case, so I'm not sure if adding buttons and asking users to look for words is the right way forward.

As for making the request be a plain ajax call, there's actually a two-fold reason this hasn't been done.

Due to how the update filter is added, it does not exist within a call to admin-ajax.php, and leaving it open to a plain request without going via there leaves it open to unintended information sharing about a potential security issue on a site.

Do you have any suggestions for improving the texts used here to make it bore clear that this may not always be a problem ?

#4 @Clorith
2 years ago

  • Keywords reporter-feedback added

Following up on this ticket @stephankn to hear if this is still an issue? The logic on how this check is performed has been reworked a bit since this ticket was opened.

#5 @stephankn
2 years ago

  • Keywords reporter-feedback removed
  • Resolution set to worksforme
  • Status changed from new to closed

@Clorith I checked with version 6.0.1. The misleading warning is no longer printed.

I see no resolution "magically fixed by something else", so closing with a different resolve. Feel free to add further details, but I think this is not worth the effort doing history research to figure out why it was fixed.

#6 @Clorith
2 years ago

  • Keywords site-health removed
  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.