Site Health Loopback Test doesn't send admin cookies

[TimothyBlynJacobs]

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.

[Clorith]

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.

[Clorith]

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.

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

[TimothyBlynJacobs]

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.

[TimothyBlynJacobs]

Reopening for backport.

[SergeyBiryukov]

In 49997:

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.
Merges [49917] to the 5.6 branch.
Fixes #52097.
See #48105.

Core ticket resolved.

@Clorith After updating 5.6.1, my loopback request failed.
My wordpress installation is in a wordpress directory. then site_url() returns ​https://example.com/wordpress which deliver 404
Why not use home_url() if you want a front-end url ?