Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#51748 closed enhancement (invalid)

Allow customization of permission_callback errors

Reported by: plucmtl's profile plucmtl Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.7
Component: REST API Keywords:
Focuses: Cc:


When customizing the REST authentication permission_callback, the method provided must return one of: true, false or a WP_Error. In the case of that WP_Error, we are unable to modify the format output from what is hardcoded in the error_to_response method.

For example, if we would want authentication errors to return the following JSON object: {auth:false}, it would not be possible since error_to_response always hardcode the format to code, message and data.

See class-wp-rest-server.php#158

Change History (8)

#1 @plucmtl
4 years ago

An easy resolution would be to pass the returned data from error_to_response in a filter that we can then use to customize the output!

#2 @TimothyBlynJacobs
4 years ago

  • Version changed from trunk to 4.7

Thanks for the ticket @plucmtl and welcome to trac!

What is the use case for this? I think it is a strong benefit that all errors from the REST API are served in a consistent manner.

Making this filterable would also prevent WP_REST_Response::as_error() from being able to properly reconstruct the WP_Error object.

#3 @plucmtl
4 years ago

The use case is when building an API that's integrated with WordPress' REST API but doesn't necessarily have to do with WordPress. What I'm currently doing is allowing users to authenticate to our custom API namespace using API Keys and Tokens stored in their usermeta. I'm doing this because we are shifting our previous, custom API to integrate with WordPress - but in order to do that without changing our mobile client, we need to be able to control how the errors are output so that they can be processed, without format changes, by the client. I would argue that if you can control the success output, you should be able to control the error output as well.


#4 @TimothyBlynJacobs
4 years ago

@plucmtl In that case, I'd recommend just returning a WP_REST_Response object instead of a WP_Error. Then you can implement your error response in any way you'd like.

I think it is important that a WP_Error object can be successfully converted back and forth using those two API methods.

#5 @plucmtl
4 years ago

@TimothyBlynJacobs that's not possible, because permission_callback's return must be true, false or a WP_Error. We cannot return something custom in that method because it would otherwise mislabel the actual authorization outcome - i'm assuming that's where you're suggesting we return a manually crafted WP_REST_Response.

#6 @TimothyBlynJacobs
4 years ago

I'd recommend using the rest_post_dispatch or rest_pre_echo_response filters to modify your WP_Error response for your specific requests.

I don't think we want to support modifying the error response in an official manner like that for the reasons I outlined. Additionally, it'd be a poor choice since it doesn't have access to the WP_REST_Request object to ensure this only happens for certain routes.

#7 @plucmtl
4 years ago

  • Resolution set to invalid
  • Status changed from new to closed

Indeed, this achieves the same thing:

add_filter('rest_post_dispatch', function(\WP_HTTP_Response $response){
  // Check if it's a login error
  if ($response->is_error()) {
    $error = $response->as_error();
    // if it is, force it to go through our response filtering
    if ($error->get_error_code() == self::ERR_NOT_AUTHENTICATED) return self::respondWith($error);
  return $response;

#8 @desrosj
4 years ago

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