131
I prefer simplicity and using the first example but I'd be happy to hear other options. Here's a few examples:
HTTP/1.1 403 POST /endpoint
{ "message": "Unauthorized access" }
HTTP/1.1 403 POST /endpoint
Unauthorized access (no json)
HTTP/1.1 403 POST /endpoint
{ "error": "Unauthorized access" }
HTTP/1.1 403 POST /endpoint
{
"code": "UNAUTHORIZED",
"message": "Unauthorized access",
}
HTTP/1.1 200 (🤡) POST /endpoint
{
"error": true,
"message": "Unauthorized access",
}
HTTP/1.1 403 POST /endpoint
{
"status": 403,
"code": "UNAUTHORIZED",
"message": "Unauthorized access",
}
Or your own example.
I don't have a response to share but I always lose my mind when I see AWS error messages, especially when using bazillion layers like CDK for Terraform, executed from the shell script that runs a python script in the CI/CD pipeline.
One of the issues I will never forget was the debugging of permission issue. Dev reported an issue, something like "cannot access the SQS queue from a recently deployed script". The error message was like "cannot access the queue due to missing policy in assumed role" (or something similar). So, I have checked the python script and related policies - all good. Next I've moved to a shell script, still no luck. After that I went through the CDK files, no issues. I was about to involve the AWS support when it turned out that the queue name has been changed manually in the AWS console. AWS, instead of point out that the queue is missing, raised an error about missing access permissions...
It usually goes down like this on some security heavy system: It does not know that a queue is missing. It does however know that it cannot access that queue. When an error is thrown on a secure system, usually the first thing to check is the privilege. If the queue does not exist, so does the privilege to access said queue hence the first error being thrown.
Ugh, poor error reporting is such a frustrating time sink.