-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
❗ NOTICE (aws-apigateway): Authorization Scopes not rendered with CognitoUserPoolsAuthorizer #30444
❗ NOTICE (aws-apigateway): Authorization Scopes not rendered with CognitoUserPoolsAuthorizer #30444
Comments
Yeah, just upgraded to the latest CDK and all the scopes were blown away. This is pretty bad. |
You can do the following workaround until it’s fixed: const restApi = new RestApi(stack, "RestApi", {
deploy: true,
defaultMethodOptions: {
authorizer,
// setting it explicit:
authorizationType: authorizer.authorizationType,
},
}); |
Hey @t0bst4r , thanks for reporting this. could you please share the output of |
This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
Yes, I’ll provide it tomorrow. |
I created a new AWS account, created a new CDK project using import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import {CognitoUserPoolsAuthorizer, MockIntegration, RestApi} from "aws-cdk-lib/aws-apigateway";
import {OAuthScope, UserPool} from "aws-cdk-lib/aws-cognito";
export class CdkTestStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const userPool = new UserPool(this, "UserPool");
const authorizer = new CognitoUserPoolsAuthorizer(this, "Authorizer", {
cognitoUserPools: [userPool]
});
const restApi = new RestApi(this, 'CdkTestStack', {
defaultMethodOptions: {
authorizer,
authorizationScopes: [OAuthScope.PROFILE.scopeName]
}
});
restApi.root
.resourceForPath("/user")
.addMethod("GET", new MockIntegration());
restApi.root
.resourceForPath("/other")
.addMethod("POST", new MockIntegration(), {
authorizationScopes: [OAuthScope.OPENID.scopeName]
});
}
} I bootstrapped the account and deployed the application:
Then I updated to
Then I change the cdk code to include an EXPLICIT authorization type: import * as cdk from 'aws-cdk-lib';
import {Construct} from 'constructs';
import {CognitoUserPoolsAuthorizer, MockIntegration, RestApi} from "aws-cdk-lib/aws-apigateway";
import {OAuthScope, UserPool} from "aws-cdk-lib/aws-cognito";
export class CdkTestStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const userPool = new UserPool(this, "UserPool");
const authorizer = new CognitoUserPoolsAuthorizer(this, "Authorizer", {
cognitoUserPools: [userPool]
});
const restApi = new RestApi(this, 'CdkTestStack', {
defaultMethodOptions: {
authorizer,
authorizationScopes: [OAuthScope.PROFILE.scopeName],
authorizationType: authorizer.authorizationType // <-- ONLY CHANGED LINE
}
});
restApi.root
.resourceForPath("/user")
.addMethod("GET", new MockIntegration());
restApi.root
.resourceForPath("/other")
.addMethod("POST", new MockIntegration(), {
authorizationScopes: [OAuthScope.OPENID.scopeName]
});
}
} Then running
In my first post, I linked to the lines that are most likely the cause of this problem. |
Thanks @t0bst4r for sharing the code and diff snippet. I can see the difference in the template generated in CDK 2.148.0. Thanks for reporting this. Marking it as P1 as its a regression and should be fixed. |
Thanks for the report. I can confirm that this is a regression and we will treat it as |
As another workaround you can pin the aws-cdk-lib version to |
Update notice for aws/aws-cdk#30444
|
1 similar comment
|
… defining authorization type in method or root api (#30822) ### Issue # (if applicable) Closes #30444 ### Reason for this change The original PR caused a breaking change, we can't rollback because it was released in v2.142.0 and it fixes customers issues (partially). Simply doing a revert will be breaking for those customers again. ### Description of changes Identified the root cause and we should use `AuthorizationType` instead of `AuthorizationTypeOption`. `AuthorizationType` defaults to find the authorization type from the authorizer, falling back to use the auth type defined in the `Method` construct's options property and falling back to `None`. `AuthorizationTypeOptions` on the other hand tries to find the auth type from `Method` construct's options property which can be None because it's optional. ### Description of how you validated changes New unit tests covering the changes and new integration tests covering it. ### Checklist - [ ] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license* --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
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. |
Please add your +1 👍 to let us know you have encountered this
Status: IN-PROGRESS
Overview:
Describe the bug
When using the
CognitoUserPoolsAuthorizer
withauthorizationScope
, the scopes are not rendered to the CloudFormation template, ifauthorizationType
is not set explicitly. This worked before version2.142.0
.Expected Behavior
Scopes are rendered to the CloudFormation template when using CognitoUserPoolsAuthorizer without setting authorizationType explicitly. The authorizationType of the authorizer should be used implicitly.
Current Behavior
Scopes are not rendered to the CloudFormation template when using CognitoUserPoolsAuthorizer without setting authorizationType explicitly. They are only rendered, when authorizationType is set explicitly.
A warning is printed during CDK synth:
Reproduction Steps
Workaround:
There are 2 workarounds:
2.141.0
.Solution:
We are reverting this PR that introduces the breaking change.
The text was updated successfully, but these errors were encountered: