[BUG]: Making a request with a malformed Bearer token returns 500 Server Error, and payload validation is done before authorization is checked.

[neekfenwick]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

Sending an invalid value in the Authorization header for the Bearer token for an otherwise valid request causes the server to respond with a status code of 500 and content:

{ "error": "Server Error" }

Then, changing the request to be invalid by omitting a mandatory field causes a payload validation error to be returned, instead of the consistent error response because of the invalid Authorization header.

Providing an Authorization header that is nearly correct but has extra characters, for example providing a valid access_token value with 'xxx' appended, returns a 401 Unauthorized response with body:

{ "error": "invalid_token", "error_description": "access_token is invalid" }

Two problems seem apparent: 1/ The error message returned when the Authorization header contains the wrong kind of code returns a 500 Server Error instead of 'access_token is invalid' (making debugging the overall request difficult) 2/ The request payload e.g. createDraftListing is validated before any authorization checks made the request illegal.

Steps to reproduce

1. Prepare a normal request for an endpoint, in my case it was in Postman for the createDraftListing endpoint
2. When setting the Authorization header, accidentally use the 'code' value usually sent to the publish/oauth/token endpoint, instead of the access_token value that is expected. In postman, I set the Authorization type to "Bearer Token" and in the "Token" field the value for 'code', "i3KQ1gyD7hOv....."
3. Send the request and observe the 500 'Server Error' response.
4. Thinking the request payload was incorrect, remove the 'description' field from the createDraftListing request, and send, still with the wrong Bearer token.
5. Observe a 400 response { "error": "Missing input parameter: [description]" }
6. Spend ages trying to figure out what's wrong with your payload before realising the Bearer token is incorrect.
7. Put the correct Bearer token in and re-sent the request.
8. Observe a 200 response.
9. Add 'xxx' to the valid Bearer token and remove the 'description' field from the payload.
10. Observe the 400 response { "error": "Missing input parameter: [description]" } as seen in step 5.

Expected behavior

When an incorrect Authorization header is provided, a consistent response indicating the access token is invalid should be returned with something like a 401 status code.

Removing one of the payload's required fields should not change this response. However, a slightly corrupted Bearer token while changing the payload to be incorrect returned a validation error about the payload. This indicates that the payload is being validated and reported on, before the authorisation header is inspected to see if the request should be attempted at all.

Additional context

No response