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
feat(cognito): add mutable property in cognito user pool custom attribute #7190
feat(cognito): add mutable property in cognito user pool custom attribute #7190
Conversation
Add properties `mutable` and `developerOnly` to all CustomAttribute types. fixes: aws#7011
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Custom attributes cannot be marked as required. | ||
All custom attributes share the common properties `developerOnly` and `mutable`. | ||
|
||
- `developerOnly` means that this attribute can only be modified by an administrator. The use of this property is discouraged |
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.
The use of this property is discouraged
Is this Cognito's recommendation or something you are suggesting?
If it's the former, can you point to where they are saying so?
OTOH, if it's the latter, could you explain why you are suggesting this?
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.
It is Cognito's recommendation
We recommend that you use WriteAttributes in the user pool client to control how attributes can be mutated for new use cases instead of using DeveloperOnlyAttribute.
from AWS::Cognito::UserPool SchemaAttribute in Cloudformation
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.
In such a case, should the CDK even implement this? Can we instead implement WriteAttributes on the client, so users use the right thing?
For users who really want to use this attribute or if they're migrating an existing user pool to the CDK, they can always access this via CDK's escape hatches.
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 like your point.
I think the implementation might involve changing the UserPoolClient
class to allow set the read/write attributes for that specific client.
Do you think this should be implemented in its own issue/PR or is it fine to do it here?
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.
Do you think this should be implemented in its own issue/PR or is it fine to do it here?
A separate PR would be preferable and cleaner.
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.
Ok, I will remove the support for the developerOnly
attribute altogether and propose a new PR.
/** | ||
* Constraints that can be applied to a custom attribute of string type. | ||
*/ | ||
export interface BaseCustomAttributeProps { |
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.
Drop the prefix Base
from here.
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.
Done ✅
* All common properties are set here and the method `baseAttributeConfig` | ||
* should be used by subclasses to create base CustomAttributeConfig object inside the `bind()` method. | ||
*/ | ||
abstract class BaseCustomAttribute implements ICustomAttribute { |
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.
Same here. Let's drop 'Base'.
Unfortunately, if an exported class inherits this, this will also need to be exported.
abstract class BaseCustomAttribute implements ICustomAttribute { | |
export abstract class CustomAttribute implements ICustomAttribute { |
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.
Done ✅
- `developerOnly` means that this attribute can only be modified by an administrator. The use of this property is discouraged | ||
in favour of the use of write permissions for attributes in the user pool client (see [AppClients](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html)), | ||
|
||
- `mutable` allows the value to be changed after the value is set by the user. |
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.
Does setting mutable
to false
mean that even administrators can't modify it?
In general, is there a combination of mutable
and developerOnly
that is invalid or does not make sense?
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.
Great question.
Yes, setting mutable
to false
means that even administrators can't modify it but it still make sense to keep both properties in case the users are allowed to sign up by themselves.
If only admins (==developers) can create new users than mutable && developerOnly
has the same meaning of mutable
because the attribute must be set on creation and only developers can do it.
If sign up is enabled, then mutable && developerOnly
on an attribute means that only users created via the AdminCreateUser
api can have that attribute set while users created via the SignUp
API will never be able to set it.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
The default behavior for CloudFormation is for the attributes to be immutable. Changing the default would lead to a breaking change. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
* All common properties are set here and the method `baseAttributeConfig` | ||
* should be used by subclasses to create base CustomAttributeConfig object inside the `bind()` method. | ||
*/ | ||
export abstract class CustomAttribute implements ICustomAttribute { |
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 don't see much value in this base class anymore, now that we've dropped the adminOnly property.
It would be simpler to just store the mutable
value as an instance property in each class and return it as part of bind()
. And to revert the data type to how it was modeled previously.
What do you think?
Let's keep the same default as CloudFormation. |
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.
Moving this to request changes. Let's remove the base class here.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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've made slight adjustments to the test statements. Hope that's ok.
LGTM otherwise.
Looks great for me! |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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). |
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). |
This PR adds missing property
mutable
to custom attributes in Cognito User Pool.The properties are add to all data types (String, Number, Boolean and DateTime) as per CloudFormation docs.
Required
property must be false for custom attributes, so is not added.closes: #7011
Pull Request Checklist
user-pool-attr.test.ts
filedesign
folder N.A.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license