chalice
chalice copied to clipboard
Extend Custom Authorizer Support API Gateway Request Parameter
I noticed that the custom authorizer implementation makes the assumption that authorization will come strictly from the header. Specifically, the CustomAuthorizer only allows header
:
https://github.com/aws/chalice/blob/cb3059551da903accff7d91d710fc998adfc1289/chalice/app.py#L203-L212
And the local server assumes type TOKEN
and a header of authorization
:
https://github.com/aws/chalice/blob/cb3059551da903accff7d91d710fc998adfc1289/chalice/local.py#L382-L385
However, the API Gateway Lambda Authorization documentation specifies:
When a client calls your API, API Gateway verifies whether a Lambda authorizer is configured for the API method. If so, API Gateway calls the Lambda function. In this call, API Gateway supplies the authorization token that is extracted from a specified request header for the token-based authorizer, or passes in the incoming request parameters as the input (for example, the event parameter) to the request parameters-based authorizer function.
And the specific line of note is: or passes in the incoming request parameters as the input. So the change would be to allow either TOKEN
or REQUEST
types. Obviously more details need to be ironed out, but I wanted to start a discussion first.
What do others think of this extension?
Marking as a feature request to track interest. What do you gain with this feature? The tangible benefits seem really small compared to the work to add it. Is this a blocker for some integration or feature elsewhere that may be of interest?
Yea, this came about because of an integration that I'm dealing with. Specifically, the integration sends a JWT in the query parameters instead of the header, and, unfortunately, they are unlikely to change this. It seemed appropriate to be able to group all of the authorization into authorizers and handle the logic in one specific function using the same decorator syntax as other authorizers.
My workaround is to have it "unauthorized" and then immediately call some method to act as the authorizer and throw a chalice.UnauthorizedError myself.
You're right the tangible benefits are probably small seeing as it's simple enough to do the work around. So I guess not high priority.
This feature would be very valuable. This is primarily because a REQUEST
authorizer will be passed the stage variables of the "source" RestAPI.
This way I can create a custom authorizer looking at JWT claims, but specify in the RestAPI which claim "this" particular RestAPI should look for.
I'm interested in seeing this supported by chalice. I'm working on a slack integration and the authorization is made by verifying slack request signature. Which comes in the request headers so the current assumptions of token authorizations prevent me to use it.
If it's not planeed how could i workaround this limitation? Perhaps a sublass of CustomAuthorizer
?
I implemented a decorator that wraps every view but I still thinks it's suboptimal
I needed this feature too, but I just went for the subclassing solution:
class RequestCustomAuthorizer(CustomAuthorizer):
'''
Overwrite CustomAuthorizer to support 'Request' type
'''
def to_swagger(self) -> Dict[str, Any]:
swagger: Dict[str, Any] = {
'in': 'header',
'type': 'apiKey',
'name': self._header,
'x-amazon-apigateway-authtype': self._AUTH_TYPE,
'x-amazon-apigateway-authorizer': {
'type': 'request',
'authorizerUri': self._authorizer_uri,
'authorizerResultTtlInSeconds': self._ttl_seconds,
}
}
if self._invoke_role_arn is not None:
swagger['x-amazon-apigateway-authorizer'][
'authorizerCredentials'] = self._invoke_role_arn
return swagger
Needless to say, this works for my specific Chalice version. You can look at the version you are using and subclass it accordingly.
Not the ideal solution, but it works.
We sincerely hope that chalice will support the API Gateway Request Parameter, which is essential for many of our use cases.