-
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
fix(iam): AccountPrincipal accepts values which aren't account IDs #20292
Conversation
Changed the type of accountId in AccountPrincipal constructor to string from any to fix issue #20288
The parameter accountId was having the type 'any' and being assigned to a data member of class AccountPrincipal called principalAccount which is of type 'string | undefined'. accountId and principalAccount are meant to hold the AWS account id which should be in the form of string. Changing the type annotation of accountId as parameter in AccountPrincipal constructor won't have any other effects other than specifying the TypeScript linter the type of the parameter accountId. There doesn't seem to be any other reason for the type of accountId to be 'any' since this parameter is only part of the constructor, and will be used to create the stack dependent token and assigning to principalAccount in the constructor. The format of the stack dependent token only works with valid accountId, and the principalAccount should also be valid accountId. If you pass an object, it should give you TypeError to indicate the error in the format given to the AccountPrincipal constructor. |
Seems like a check compatibility issue: check-api-compatibility.sh function _aws_cdk_aws_iam_AccountPrincipal(p) {
}
...
module.exports = { ..., _aws_cdk_aws_iam_AccountPrincipal, ... }; The build is failing because of this. Adding it to allowed-breaking-changes.txt |
Added `incompatible-argument:@aws-cdk/aws-iam.AccountPrincipal.<initializer>` to allowed-breaking-changes.txt to fix the build error.
@rix0rrr can you review this PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this is poor choices in the past, but unencoded tokens (IResolvable
) are accepted here, and the change would require code changes by consumers (i.e., not acceptable).
We have to change this into a run-time check, unfortunately:
if (!Token.isUnresolved(accountId) && typeof accountId !== 'string') {
throw new Error('...');
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this change inside the constructor and reverted back to any. Should this be a fix or a chore?
Added run time check for accountId type and added appropriate error message for that. Reverted the type annotation for accountId to any
any
Both are reasonable. You can call it a |
|
Fixed the error ```bash @aws-cdk/aws-iam: lib/principals.ts:395:3 - error TS2376: A 'super' call must be the first statement in the constructor when a class contains initialized properties, parameter properties, or private identifiers. ```
@rix0rrr can you review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still needs a test, and the breaking changes except is no longer necessary
any
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
…ws#20292) Changed the type of accountId in AccountPrincipal constructor to string from any fixes aws#20288 ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/master/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/master/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*
---- ### All Submissions: * [x] 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* --- With the merge of [#20292](#20292) the accountID type was essentially required to be a string with the exception of an unencoded token. So, while the type of accountId cannot be set to string and must remain any to preserve compatibility, the hint for accountId should at least suggest that a string should be used rather than an int.
Changed the type of accountId in AccountPrincipal constructor to string from any fixes #20288
All Submissions:
Adding new Unconventional Dependencies:
New Features
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