feat(apigatewayv2-authorizers): add payloadFormatVersion field to HttpLambdaAuthorizer

[yasamoka]

Issue

Closes #21492.

Reason for this change

Allows one to set the payload format version to 2.0 when IAM response type is requested.

BREAKING CHANGE: responseTypes array field was replaced with responseType enum in HttpLambdaAuthorizer

Description of changes

Previously, the CDK would not allow the payload format version to be set manually and would automatically set the version to 1.0 if IAM response type is requested.

This change allows for the use of either payload format version 1.0 or 2.0 when IAM response type is requested. Previous behavior is respected:

• when none of the fields are defined, the payload format version is set to 1.0 and the response type is set to IAM.
• When the response type is set to IAM, the payload format version is set to 1.0.
• When the response type is set to simple, the payload format version is set to 2.0.

In reverse as well, setting the payload format version to 1.0 sets the response type to IAM, while setting the version to 2.0 sets the response type to simple.

Furthermore, when attaching an authorizer in API Gateway using the web interface, the response type is a radio button group allowing either simple or IAM response type, but not both. Attempting to provide responseTypes as an array containing both in a CDK deployment results in only simple showing up and IAM policy responses failing. The fix for responseTypes brings the behavior in the CDK in line with that shown in the web interface.

Description of how you validated changes

I have added unit tests according to the following truth table:

payloadFormatVersion	responseType	payloadFormatVersion (out)	enableSimpleResponses
undefined	undefined	1.0	false
undefined	simple	2.0	true
undefined	IAM	1.0	false
1.0	undefined	1.0	true
1.0	simple	ERROR	ERROR
1.0	IAM	1.0	false
2.0	undefined	2.0	true
2.0	simple	2.0	true
2.0	IAM	2.0	false

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 1ed6ae9
• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[yasamoka]

Exemption Request

From the contribution guideline:

The only case where it is legitimate to break a public API is if the existing API is a bug that blocked the usage of a feature. This means that by breaking this API we will not break anyone, because they weren't able to use it. The file allowed-breaking-changes.txt in the root of the repo is an exclusion file that can be used in these cases.

I would argue that this breaking change qualifies for this criterion.

Previously, users would deal with 1 of 4 variants of responseTypes in HttpLambdaAuthorizer:

• undefined: this leads to correct behavior and remains unchanged.
• [HttpLambdaResponseType.SIMPLE]: this leads to correct behavior and the only change required is to replace with HttpLambdaResponseType.SIMPLE.
• [HttpLambdaResponseType.IAM]: this leads to correct behavior and the only change required is to replace with HttpLambdaResponseType.IAM.
• [HttpLambdaResponseType.SIMPLE, HttpLambdaResponseType.IAM]: this leads to incorrect behavior since IAM responses no longer work after deployment even though the provided array seems to suggest that it would. In the web interface, Simple is chosen rather than IAM in a radio button group. This is no longer allowed with the breaking change.

Please advise on how to proceed and whether there is a solid path forward to not introduce a breaking change as I cannot think of a solution that is not messy given that there seems to be a bug and that this breaking change both resolves the bug and paves the way forward to implementing a feature.

Thank you very much.

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ Breaking changes in stable modules [apigatewayv2-authorizers] is disallowed.

PRs must pass status checks before we can provide a meaningful review.

If you would like to request an exemption from the status checks or clarification on feedback, please leave a comment on this PR containing Exemption Request and/or Clarification Request.

✅ A exemption request has been requested. Please wait for a maintainer's review.