Validate authorizer context response to better mimic API Gateway (resubmit) #1376
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dherault
approved these changes
Apr 13, 2022
|
Yessir! Thanks for the review. |
|
Published in v8.7.0 |
This was referenced Apr 20, 2022
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
When successfully returning a policy from an Authorizer function, if the returned policy contains a context object containing values that are not of type
string,number, orboolean, it will cause the endpoint to return 500, with the header:x-amzn-ErrorType: AuthorizerConfigurationException. In addition,string,number, andbooleanvalues returned in the authorizer context are all coerced to string values when supplied to the downstream method implementation lambda.None of this behavior is currently accounted for in the serverless-offline authorizer handling logic. This change fixes that issue, and makes serverless-offline authorizers behave near exactly like those of ApiGateway.
Motivation and Context
This change helps prevent developers from returning invalid types of authorizer contexts that work in serverless-offline but do not work on AWS. This change also helps developers understand exactly what the
event.requestContext.authorizerproperty will contain in the cloud.fixes #826
How Has This Been Tested?
I began by experimenting with the authorizer context response in ApiGateway with a pair of lambdas, one authorizer, and one downstream method implementation. I confirmed the string coercion behavior as described in this developer guide. I used the current authorizer integration tests as a starting point and added four context validation tests, ensuring that each type of valid and invalid context mimicked the behavior of ApiGateway authorizers as closely as possible.