#51748 closed enhancement (invalid)
Allow customization of permission_callback errors
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.7 |
Component: | REST API | Keywords: | |
Focuses: | Cc: |
Description
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)
#2
@
3 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
@
3 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.
Thanks!
#4
@
3 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
@
3 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
@
3 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
@
3 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;
});
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!