- 新しい順
- 投票が多い順
- コメントが多い順
Yes, it's possible to have the API Gateway respond with a 401 status code instead of a 403 based on specific conditions in your request-based authorizer.
In your request-based authorizer function, you can conditionally return a deny policy with either a 403 or a 401 status code based on your logic. Here's an example of how you can achieve this in Node.js:
exports.handler = async (event, context) => {
// Your authorization logic here
if (/* Your condition for returning 401 */) {
// Return a deny policy with a 401 status code
return {
"principalId": "user",
"policyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Action": "execute-api:Invoke",
"Effect": "Deny",
"Resource": event.methodArn,
"Context": {
"statusCode": 401,
"message": "Unauthorized"
}
}]
}
};
} else {
// Return a deny policy with a 403 status code
return {
"principalId": "user",
"policyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Action": "execute-api:Invoke",
"Effect": "Deny",
"Resource": event.methodArn,
"Context": {
"statusCode": 403,
"message": "Forbidden"
}
}]
}
};
}
};
In this example, you can replace /* Your condition for returning 401 */ with your specific condition. If this condition is met, the authorizer will return a deny policy with a 401 status code. Otherwise, it will return a deny policy with a 403 status code.
Remember to deploy your updated authorizer function after making these changes, and test it to ensure it behaves as expected.
Hope it clarifies and if does I would appreciate answer to be accepted so that community can benefit for clarity, thanks ;)
This doesn't work. You are returning an invalid policyDocument (the Context property does not belong there) which leads to an AuthorizerConfigurationException which, without any further configuration, should end up as a 500 response. You could add a context (lowercase) property to the response as a sibling of policyDocument, but that still does nothing to the overall API Gateway response which in this case will be a 403 from the explicit Deny. You could use that context in a custom Gateway Response for the ACCESS_DENIED response type and return a 401 instead of a 403 that way. But just by modifying the response from the Lambda you cannot change the status code of the response from API Gateway. Note that that context has to be a simple key/value object or else you'll get a AuthorizerConfigurationException as well.