Make WordPress Core

Opened 4 weeks ago

Last modified 2 weeks ago

#52097 reopened defect (bug)

Site Health Loopback Test doesn't send admin cookies

Reported by: TimothyBlynJacobs Owned by: TimothyBlynJacobs
Milestone: 5.6.1 Priority: normal
Severity: normal Version: 5.6
Component: Site Health Keywords: has-patch fixed-major
Focuses: rest-api Cc:


In WordPress 5.6 we moved the async Site Health tests to use the REST API. One of those tests is the loopback test which makes a request to admin_url(). We send along any cookies in the request so that the user is authenticated for this admin request.

However, now that the REST API is used, the admin-specific authentication cookies are not included. This effectively means that the user isn't authenticated. You can see this in practice by inspecting the loopback response. The user is being redirected to wp-login.php.

This causes false positives with plugins that attempt to obscure wp-login.php or have additional authentication blocking wp-login.php from being loaded.

Discussing in #core-site-health, it may be better to change this test to use a front-end URL for 5.6.1 and in the future add specific tests for making sure the file editor save checks work in 5.7.

Change History (5)

#1 @Clorith
4 weeks ago

There's another ticket also relying on being logged in to pass around login checks... so thinking out loud, would it make sense to provide the basic test here towards site_url() as discussed (I believe this is the best way forward, and is what will happen for 5.6.1 any way), but to resolve the other false positive, there's no good solution without faking a user session as it stands right now.

Introducing a live_only boolean entry to the tests, this would be purely optional, but if set, tests would not run during cron events, we could then block off tests like checking if the REST Endpoint for editing a post is valid, since it requires a logged in session with the appropriate capabilities to run.

This would also allow for more flexibility inside tests, we would then do the basic loopback check towards site_url() in the case of this ticket during cron events, then when a logged in user checks site health manually, it could also perform the additional check towards admin_url() and give extended information if something should be wrong there?

The alternative would be to create a fake instance to an admin account, log it in, run tests, log it back out, which feels wrong to me.

#2 @Clorith
4 weeks ago

Of course, I was a bit too quick on the trigger, since the problem of the auth would still be there for this instance, and we've already got skip_cron 🤔

Let's start this one off by just fixing the loopbacks then, and brainstorming for 5.7 could be in a separate ticket.

This ticket was mentioned in PR #830 on WordPress/wordpress-develop by Clorith.

4 weeks ago

  • Keywords has-patch added

#4 @TimothyBlynJacobs
2 weeks ago

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

In 49917:

Site Health: Use a front-end URL for loopback tests.

In [49154] the async Site Health tests were changed to use the REST API instead of admin-ajax. An unintended side effect of this change was that the loopback tests which tried to ping the site's admin_url() were no longer authenticated because admin-cookies aren't provided to the REST API.

This commit adjusts the loopback test to use the front-end site_url which checks that cron will function properly. A follow-up ticket will focus on tests that will cover the file editor checks.

Props Clorith.
Fixes #52097.
See #48105.

#5 @TimothyBlynJacobs
2 weeks ago

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

Reopening for backport.

Note: See TracTickets for help on using tickets.