-
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
defaultMethodOptions should be selectively applied to CORS OPTIONS method #8615
Comments
Thanks for filing this issue @whimzyLive. The 'OPTIONS' method created as part of CORS preflight setup will have to be adjusted such that only properties in For the time being, you should be able to work around this using escape hatches. |
I stumbled across this too. For now, I have removed the API key requirement from the RestApi and added it to each resource instead. This isn't ideal though. |
@asterikx until issue is resolved correctly, you can use cdk escape hatches as also suggested by @nija-at. For my case I did const corsMethods = this.apiV1.methods.filter(
method => method.httpMethod === 'OPTIONS'
);
corsMethods.forEach(method => {
const cfnMethod = method.node.defaultChild as CfnMethod;
cfnMethod.addPropertyOverride('ApiKeyRequired', false);
cfnMethod.addPropertyOverride('AuthorizationType', 'NONE');
cfnMethod.addPropertyDeletionOverride('AuthorizerId');
}); |
@whimzyLive thanks for sharing! I wasn't sure how to do this. |
There are extra issues with this and proxy support AFAICT. For example, using const api = new apigateway.LambdaRestApi(stack, 'DummyApi', {
handler,
defaultMethodOptions: { authorizationType: apigateway.AuthorizationType.IAM },
defaultCorsPreflightOptions: { allowOrigins: apigateway.Cors.ALL_ORIGINS },
})
api.methods.filter(m => m.httpMethod === 'OPTIONS')
.forEach(m => m.node.defaultChild.addPropertyOverride('AuthorizationType', 'NONE')) This works in so much as the OPTIONS methods are changed correctly in the CFN output to not use auth – but I still get 403s when sending OPTIONS requests – and I believe (although happy to be wrong) it's because the auth on the EDIT: this was wrong. I believe the root cause is that the CDK is failing to see the I'm guessing EDIT2: Added an issue for this over at #9086 |
I guess this is akin to the |
Another related issue here (if not exactly the same): #906 (comment) |
@mhart I am using |
Like I said, I'm pretty sure the generated CFN is actually right – I mean, it's removed the auth from OPTIONS – the problem is that (I suspect) the auth on the Anyway, here are the generated EDIT: Updated – I only had the two proxy methods in before, now have all four (two proxy + two root): {
"DummyApiOPTIONSA607B51F": {
"Type": "AWS::ApiGateway::Method",
"Properties": {
"HttpMethod": "OPTIONS",
"ResourceId": {
"Fn::GetAtt": [
"DummyApi80F1E171",
"RootResourceId"
]
},
"RestApiId": {
"Ref": "DummyApi80F1E171"
},
"AuthorizationType": "NONE",
"Integration": {
"IntegrationResponses": [
{
"ResponseParameters": {
"method.response.header.Access-Control-Allow-Headers": "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,X-Amz-User-Agent'",
"method.response.header.Access-Control-Allow-Origin": "'*'",
"method.response.header.Access-Control-Allow-Methods": "'OPTIONS,GET,PUT,POST,DELETE,PATCH,HEAD'"
},
"StatusCode": "204"
}
],
"RequestTemplates": {
"application/json": "{ statusCode: 200 }"
},
"Type": "MOCK"
},
"MethodResponses": [
{
"ResponseParameters": {
"method.response.header.Access-Control-Allow-Headers": true,
"method.response.header.Access-Control-Allow-Origin": true,
"method.response.header.Access-Control-Allow-Methods": true
},
"StatusCode": "204"
}
]
}
},
"DummyApiproxyOPTIONSC056BEDA": {
"Type": "AWS::ApiGateway::Method",
"Properties": {
"HttpMethod": "OPTIONS",
"ResourceId": {
"Ref": "DummyApiproxy55B1C1CD"
},
"RestApiId": {
"Ref": "DummyApi80F1E171"
},
"AuthorizationType": "NONE",
"Integration": {
"IntegrationResponses": [
{
"ResponseParameters": {
"method.response.header.Access-Control-Allow-Headers": "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,X-Amz-User-Agent'",
"method.response.header.Access-Control-Allow-Origin": "'*'",
"method.response.header.Access-Control-Allow-Methods": "'OPTIONS,GET,PUT,POST,DELETE,PATCH,HEAD'"
},
"StatusCode": "204"
}
],
"RequestTemplates": {
"application/json": "{ statusCode: 200 }"
},
"Type": "MOCK"
},
"MethodResponses": [
{
"ResponseParameters": {
"method.response.header.Access-Control-Allow-Headers": true,
"method.response.header.Access-Control-Allow-Origin": true,
"method.response.header.Access-Control-Allow-Methods": true
},
"StatusCode": "204"
}
]
}
},
"DummyApiproxyANY1EBD4910": {
"Type": "AWS::ApiGateway::Method",
"Properties": {
"HttpMethod": "ANY",
"ResourceId": {
"Ref": "DummyApiproxy55B1C1CD"
},
"RestApiId": {
"Ref": "DummyApi80F1E171"
},
"AuthorizationType": "AWS_IAM",
"Integration": {
"IntegrationHttpMethod": "POST",
"Type": "AWS_PROXY",
"Uri": {
"Fn::Join": [
"",
[
"arn:",
{
"Ref": "AWS::Partition"
},
":apigateway:",
{
"Ref": "AWS::Region"
},
":lambda:path/2015-03-31/functions/",
{
"Fn::GetAtt": [
"DummyFunction3BB5AE03",
"Arn"
]
},
"/invocations"
]
]
}
}
}
},
"DummyApiANYCEB66499": {
"Type": "AWS::ApiGateway::Method",
"Properties": {
"HttpMethod": "ANY",
"ResourceId": {
"Fn::GetAtt": [
"DummyApi80F1E171",
"RootResourceId"
]
},
"RestApiId": {
"Ref": "DummyApi80F1E171"
},
"AuthorizationType": "AWS_IAM",
"Integration": {
"IntegrationHttpMethod": "POST",
"Type": "AWS_PROXY",
"Uri": {
"Fn::Join": [
"",
[
"arn:",
{
"Ref": "AWS::Partition"
},
":apigateway:",
{
"Ref": "AWS::Region"
},
":lambda:path/2015-03-31/functions/",
{
"Fn::GetAtt": [
"DummyFunction3BB5AE03",
"Arn"
]
},
"/invocations"
]
]
}
}
}
}
}
} |
@mhart Okay I see you are using Lambda proxy integration in particular. For Lambda proxy This is mentioned here, under Enabling CORS support for Lambda or HTTP proxy integrations. |
That doesn't make sense – the 403 happens before the Lambda is even invoked. |
This was the last thing I could think of. If you are getting 403 on options itself then we might have had different issue. Let me know if you find out something. |
Found the issue – it was a complicated scenario with CFN stack updates and CDK deployment hashes not being updated. More info in the updated comment here: #8615 (comment) |
I also have the above issue and have come up with the same CfnMethod workaround. Couldn't believe there isn't anything better, anything official without Cfn and that maybe SAM has a solution for it though |
and how did you fix it? I'm having issues also |
Something like the below in TypeScript. Omitting referenced variables but hope it's clear. const api = new apiGateway.LambdaRestApi(
this,
"ABCD",
{
restApiName: apiName,
handler: mainFunc,
domainName: {
domainName: apiDomain,
certificate,
},
defaultCorsPreflightOptions: {
allowOrigins: corsAllowedOrigins,
},
defaultMethodOptions: { authorizer: authorizer },
}
);
api.methods
.filter((method) => method.httpMethod === "OPTIONS")
.forEach((method) => {
const methodCfn = method.node.defaultChild as apiGateway.CfnMethod;
methodCfn.authorizationType = apiGateway.AuthorizationType.NONE;
methodCfn.authorizerId = undefined;
}); |
This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue. |
When you create a RestApi and you provide `defaultCorsPreflightOptions` we automatically create a CORS OPTIONS method for each method. If you also provide `defaultMethodOptions` then those default options get passed through to the CORS OPTION method as well. In the case of authentication options this should not be the case. This PR explicitly sets the authentication related options to NONE values which overrides whatever is provided in `defaultMethodOptions`. I've updated an integration tests to assert that an OPTIONS call is successful (I also tested before the fix to assert that it failed). fixes #8615 ---- ### All Submissions: * [ ] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
@corymhall please re-open. See comment in #22402 (comment) |
Tl;DR
defaultMethodOptions
should exclude options method by default or at least have an option to do that.Read More
LambdaRestApi has
defaultMethodOption
, when it is specified, it gets applied to all methods for given api resource. which is awesome but doesn't work when CORS is involved.Take this simple example,
where I want all the methods to require
x-api-key
api key so I specifyOn top of this I also want CORS to be enabled on all api resources so in
LambdaRestApi
I also specify thisBecause of
defaultCorsPreflightOptions
an additional method will be created for all my resources to support CORS but becausedefaultMethodOption
applies on all methods, options will also haveapiKeyRequired
, which it shouldn't.Environment
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: