WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 4 weeks ago

#52112 closed defect (bug) (fixed)

get_test_rest_availability() test should point to diffrent endpoint (where no current_user_can() check is made)

Reported by: szaqal21 Owned by: Clorith
Milestone: 5.8 Priority: normal
Severity: normal Version: 5.6
Component: Site Health Keywords: good-first-bug has-patch
Focuses: Cc:

Description

Using system cron, when wp_site_health_scheduled_check event is triggered there is no way to determine user (auth cookie isn't set this causes wp_get_current_user() return "empty" user) this scenario results REST API unavailable because /wp-json/wp/v2/types/post?context=edit endpoint does caps check

<?php
if ( 'edit' === $request['context'] && ! current_user_can( $obj->cap->edit_posts ) ) {
                        return new WP_Error(
                                'rest_forbidden_context',
                                __( 'Sorry, you are not allowed to edit posts in this post type.' ),
                                array( 'status' => rest_authorization_required_code() )
                        );
                }

Triggering Site Health from wp-admin (browser) works fine because user is authenticated by auth cookie.

get_test_rest_availability() should check endpoint where no caps check is made or ?context=edit should be removed to bypass caps check.

Attachments (1)

52112.diff (899 bytes) - added by hermpheus 4 weeks ago.

Download all attachments as: .zip

Change History (9)

#1 @SergeyBiryukov
6 months ago

  • Summary changed from get_test_rest_availability() test should point to diffrent ednpoint (where no current_user_can() check is made) to get_test_rest_availability() test should point to diffrent endpoint (where no current_user_can() check is made)

#3 @TimothyBlynJacobs
5 months ago

The check including context is intentional because it allows us to determine whether Gutenberg will be able to function properly. In other words it tests that authenticated requests to the REST API work, and that query parameters are properly parsed and context evaluated.

This is probably one of the tests that should only be done in a "live" mode that @clorith mentions.

#4 @TimothyBlynJacobs
5 months ago

#52104 was marked as a duplicate.

#5 @Clorith
6 weeks ago

  • Keywords needs-patch good-first-bug added
  • Milestone changed from Awaiting Review to 5.8

With [49334] the concept of skip_cron was added to tests. This, when set, will make sure that a test can only be ran when the request comes from a user navigating to the Site Health page, and not when a cron event runs. This sounds like the same use-case as discussed here.

That means that to resolve this, one would want to add 'skip_cron' => true, to the test registration, and also replicate the check for `skip_cron` check that is in the `WP_Site_Health::wp_cron_scheduled_check()` function to also look for this in direct tests runner section.

This ticket was mentioned in PR #1268 on WordPress/wordpress-develop by hmfs.


4 weeks ago

  • Keywords has-patch added; needs-patch removed

The rest test checks an authenticated context and so is unsuitable for
running from a system cron job which has no authenticated user.

This change skips the rest test when running from cron, fixing a false
positive from temporarily appearing in the dashboard widget.

Trac #52112

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

@hermpheus
4 weeks ago

#7 @hermpheus
4 weeks ago

I can see an argument for changing the test context to ensure that the REST API works for non-authenticated users, but I also see an argument that it is more important to test that authenticated REST calls work, as is necessary for Gutenberg.

The patch attached above implements the skip_cron fix @Clorith outlines above to fix the false positive.

Thanks all.

#8 @Clorith
4 weeks ago

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

In 50939:

Site Health: Skip REST tests during scheduled events.

This change fixes a false positive that would appear during scheduled events, by only running the REST test when a user visits the Site Health page, meaning an active session is available.

The test checking if the REST API is available, includes a parameter for context=edit to make sure the block editor can function properly. This means a user session with editor capabilities is required for the test to pass, which is not the case during a scheduled event.

Props szaqal21, TimothyBlynJacobs, hermpheus.
Fixes #52112.

Note: See TracTickets for help on using tickets.