Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#52104 closed defect (bug) (duplicate)

False positive REST API error in Site Health when triggered by wp_site_health_scheduled_check event

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


I'm using system cron (DISABLE_WP_CRON = true) but I think cron type doesn't matter (system or WP Cron) and filter requests to REST API to allow only logged in users.

add_filter('rest_authentication_errors', 'force_rest_auth');

function force_rest_auth($result)
                        return $result;

                        return new WP_Error('rest_not_logged_in', __('Only authenticated users can access the REST API.', 'security-hardener'), array('status' => 401));
                return $result;

Cron events are executed with unknown user (ID 0), when a scheduled check is made for type post caps:


response code is 401 (raw response):

{"code":"rest_forbidden_context","message":"Sorry, you are not allowed to edit posts in this post type.","data":{"status":401}}

this causes false results in Site Health dashboard widget. When Site Health isn't triggered manually from wp-admin I get 2 errors in dashboard widget, but when I enter Site Health from wp-admin, only 1 error is shown.

If i hit:




in incognito tab (not logged in), both endpoints return my custom 401 error for not logged in users so my code works fine, but when I hit those endpoints in normal tab (I'm logged in):


recognizes me and returns proper result but:


doesn't recognize me:

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

current_user_can() check in get_item() method of class WP_REST_Post_Types_Controller returns false.

Change History (2)

#2 @TimothyBlynJacobs
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

I'm going to close this as a dupe of #52112. The fix will probably be the same, to exclude running this test when the user isn't logged in / not in "live" mode.

Note: See TracTickets for help on using tickets.