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 fails with the following errors:

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

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.

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

[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.

[GavinZZ]

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.

Thank you for the information! I disagree that we should allow breaking change in this case given that 3 out of the 4 scenarios are correct behaviour currently. IMO, the best way to handle this kind of scenario is to deprecate the current property and introduce a new property with the current behaviour and document this change in README accordingly.

Adding a no-exempt label given the above comment.

[aws-cdk-automation]

This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

[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.

Thank you for the information! I disagree that we should allow breaking change in this case given that 3 out of the 4 scenarios are correct behaviour currently. IMO, the best way to handle this kind of scenario is to deprecate the current property and introduce a new property with the current behaviour and document this change in README accordingly.

Adding a no-exempt label given the above comment.

Thank you for the reply!

I plan to work on this further to implement the required changes, but I did not have time to do so yet. As far as I have seen, changes were requested just a week ago, but aws-cdk-automation states that changes have been requested for 3 weeks and the PR would be closed in a week's time (which is almost now).

Could the timer be reset just so I have time to work on this PR in the next few days hopefully? Thank you very much.

[aws-cdk-automation]

This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error.

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.

[GavinZZ]

@yasamoka Sorry that the tool automatically closed the PR. I re-opened it and added an action item internally to review the close PR policy and I don't think it's valid given that this PR is closed right after discussion.

[yasamoka]

@yasamoka Sorry that the tool automatically closed the PR. I re-opened it and added an action item internally to review the close PR policy and I don't think it's valid given that this PR is closed right after discussion.

Thank you so much!