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

feat(cognito): add mutable property in cognito user pool custom attribute #7190

Merged

Conversation

tom139
Copy link
Contributor

@tom139 tom139 commented Apr 6, 2020

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

  • Testing
    • Unit test added (prefer not to modify an existing test, otherwise, it's probably a breaking change) to existing user-pool-attr.test.ts file
    • CLI change?: no
    • cdk-init template change?: no
  • Docs
    • jsdocs: All public APIs documented
    • README: README and/or documentation topic updated
    • Design: For significant features, design document added to design folder N.A.
  • Title and Description
    • Change type: title prefixed with fix, feat and module name in parens, which will appear in changelog
    • Title: use lower-case and doesn't end with a period
    • Breaking?: last paragraph: "BREAKING CHANGE: <describe what changed + link for details>"
    • Issues: Indicate issues fixed via: "Fixes #xxx" or "Closes #xxx"
  • [n/a] Sensitive Modules (requires 2 PR approvers)
    • IAM Policy Document (in @aws-cdk/aws-iam)
    • EC2 Security Groups and ACLs (in @aws-cdk/aws-ec2)
    • Grant APIs (only if not based on official documentation with a reference)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

Add properties `mutable` and `developerOnly` to all CustomAttribute
types.

fixes: aws#7011
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: e53f7a8
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

nija-at
nija-at previously requested changes Apr 8, 2020
packages/@aws-cdk/aws-cognito/README.md Show resolved Hide resolved
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
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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 {
Copy link
Contributor

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.

Copy link
Contributor Author

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 {
Copy link
Contributor

@nija-at nija-at Apr 8, 2020

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.

Suggested change
abstract class BaseCustomAttribute implements ICustomAttribute {
export abstract class CustomAttribute implements ICustomAttribute {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done ✅

Comment on lines 188 to 191
- `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.
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@mergify mergify bot dismissed nija-at’s stale review April 8, 2020 11:36

Pull request has been modified.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: 5b29492
  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: 4cb27f8
  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@tom139
Copy link
Contributor Author

tom139 commented Apr 8, 2020

The default behavior for CloudFormation is for the attributes to be immutable.
I'm not sure this is the expected behavior: do you think it might be worth changing the default to true?

Changing the default would lead to a breaking change.

@tom139 tom139 changed the title feat(cognito): add mutable and developerOnly properties in cognito user pool custom attribute feat(cognito): add mutable property in cognito user pool custom attribute Apr 8, 2020
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: 70db8d7
  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: 7a449b9
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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 {
Copy link
Contributor

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?

@nija-at
Copy link
Contributor

nija-at commented Apr 16, 2020

The default behavior for CloudFormation is for the attributes to be immutable.
I'm not sure this is the expected behavior: do you think it might be worth changing the default to true?

Changing the default would lead to a breaking change.

Let's keep the same default as CloudFormation.

Copy link
Contributor

@nija-at nija-at left a 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.

@mergify mergify bot dismissed nija-at’s stale review April 16, 2020 17:57

Pull request has been modified.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: 7b772f5
  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: 05975a6
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

nija-at
nija-at previously approved these changes Apr 17, 2020
Copy link
Contributor

@nija-at nija-at left a 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.

@mergify mergify bot dismissed nija-at’s stale review April 17, 2020 18:00

Pull request has been modified.

@tom139
Copy link
Contributor Author

tom139 commented Apr 17, 2020

Looks great for me!

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: fb8dfa3
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: 9ace0a2
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Apr 17, 2020

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-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: 5100fa1
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Apr 17, 2020

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).

@mergify mergify bot merged commit 16e85df into aws:master Apr 17, 2020
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

Successfully merging this pull request may close these issues.

UserPool - support mutable field to CustomAttributes
3 participants