Fixing REST API response format for authorization error scenario
Problem
Currently file service sends a response in following format in case mandatory headers are missing/ user is unauthorized:
{
"code": 401,
"reason": "Access denied",
"message": "The user is not authorized to perform this action"
}
This format is not consistent with the API response format prescribed here https://cloud.google.com/storage/docs/json_api/v1/status-codes#401-unauthorized . Most of other services follow the prescribed format and hence there's a need to bring file service at parity.
Expected Behaviour
The response should look like this:
{
"error": {
"code": 401,
"message": "User is unauthorized to perform this action",
"errors": [
{
"domain": "global",
"reason": "unauthorized",
"message": "User is unauthorized to perform this action"
}
]
}
}
Are the error response in other scenarios correct?
Yes
Why there is a mismatch in format for this scenario
For authorization, file service uses AuthorizationService
implemented in os-core-common
library. Like other client wrappers, this guy also throws AppException
if it encounters any error. In general, AppExceptions are not handled by APIs as it is an instance of RuntimeException. Thus the API is returning whatever response it receives from AuthorizationService as is, resulting in undesirable formatting.
Fix:
While invoking AuthorizationService from file service, I've introduced exception handling for AppException. In case the the Error code is 401
or 403
, we throw OsduUnauthorizedException
instead of AppException. OsduUnauthorizedException is already handled by *ExceptionHandler class which takes care of the formatting.
Changes in this MR
- Added try catch block in AuthorizationFiler to handle above mentioned scenarios
- Introduced a new error message in constants
- Updated the output payload for integration tests
What testing has been done:
- Tested the API response for concerned scenarios locally.
- Integration tests are GREEN