Skip to content
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

[nextjs-cdk-construct] Allow specifying the name for the the image origin request policy #2539

Open
st0nerhat opened this issue Dec 15, 2022 · 0 comments

Comments

@st0nerhat
Copy link

st0nerhat commented Dec 15, 2022

Is your feature request related to a problem? Please describe.

The AWS::CloudFront::OriginRequestPolicy resource type requires a Name to be set. For most CDK constructs, the CDK passes this requirement through to the construct properties by requiring the corresponding property to be specified. However the OriginRequestPolicy construct makes this parameter optional. If it is left empty, the CDK appends the cdk stack id with the generated logical id for the resource as the Name.

  "NextJSImageOriginRequestACA8BCD5": {
   "Type": "AWS::CloudFront::OriginRequestPolicy",
   "Properties": {
     "Name": "devNextJSImageOriginRequestE717E360"
    }
   }

This is problematic if you have two different CDK projects that use the same CDK stack name (not to be confused with the Cloudformation stack name), the same CDK logical ids for the construct hierarchy, and deploy to the same AWS account. This will end up generating the same logical Cloudformation resource id and therefore the same policy name. This will cause the Cloudformation stack to fail to deploy due to the name collision.

Describe the solution you'd like

The simple solution would be to allow consumers of the nextjs construct to optionally specify a name for the origin request policy. The default behavior will stay the same as it is now for backward compatibility but it enables a clean workaround for anyone that ends up in this situation by creating a policy name based off of the stack name or other unique key.

Describe alternatives you've considered

It might be possible to introduce a prefix to the CDK logical id of the construct which will cause it's cdk logical id to be different, but this is not a best practice for writing CDK stacks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant