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

cognito: The provider Google does not exist for User Pool eu-west_xxxx #15850

Closed
revmischa opened this issue Aug 1, 2021 · 6 comments
Closed
Assignees
Labels
@aws-cdk/aws-cognito Related to Amazon Cognito bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days.

Comments

@revmischa
Copy link
Contributor

When I deploy a stack for the first time with a UserPoolIdentityProviderGoogle resource and a client with UserPoolClientIdentityProvider.GOOGLE as a supportedIdentityProvider, I get an error:

The provider Google does not exist for User Pool eu-west-1_D4Lw3qvRK.

If I remove GOOGLE from supportedIdentityProviders the first deployment and then uncomment it after the pool is deployed all works smoothly.

Reproduction Steps

 this.userPool = new UserPool(this, "Pool", {
      userPoolName: stackName,
 })

  const supportedIdentityProviders = [UserPoolClientIdentityProvider.COGNITO]

    if (googleClientId) {
      const googleClientSecret = secrets.getSecretValue("googleOAuth")
      new UserPoolIdentityProviderGoogle(this, "Google", {
        clientId: googleClientId,
        clientSecret: googleClientSecret,
        scopes: ["profile", "email", "openid"],
        attributeMapping: {
          profilePicture: ProviderAttribute.GOOGLE_PICTURE,
          email: ProviderAttribute.GOOGLE_EMAIL,
          fullname: ProviderAttribute.GOOGLE_NAME,
        },
        userPool: this.userPool,
      })
      supportedIdentityProviders.push(UserPoolClientIdentityProvider.GOOGLE) // <-- I have to comment this out on the first deployment
    }

    // create client ID for web app
    // we need valid redirect paths
    const signInPath = "/tmp"
    const signOutPath = "/tmp"
    const hosts = [
      "http://localhost:6010",
    ]
    const webClient = this.userPool.addClient("platform-web", {
      supportedIdentityProviders,
      oAuth: {
        callbackUrls: hosts.map((h) => h + signInPath),
        logoutUrls: hosts.map((h) => h + signOutPath),
      },
    })

What did you expect to happen?

Create the pool and client

What actually happened?

Pool created but client fails

Environment

  • **CDK CLI Version :1.115.0
  • Framework Version:
  • Node.js Version: 14
  • OS :
  • **Language (Version):TS latest

Other


This is 🐛 Bug Report

@revmischa revmischa added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Aug 1, 2021
@github-actions github-actions bot added the @aws-cdk/aws-cognito Related to Amazon Cognito label Aug 1, 2021
@jumic
Copy link
Contributor

jumic commented Aug 1, 2021

Seems to be similar to issue #15692.

You have to add the dependency between the IdentityProvider and the WebClient manually.

const provider = new UserPoolIdentityProviderGoogle(this, "Google", {
// ...

Specify dependency:

webClient.node.addDependency(provider);

After this change, the IdentityProvider will be deployed first. Then, the WebClient will be created. The deployment will not fail anymore because it can find the referenced IdentityProvider (which is created before).

--> As already proposed in #15692, this solution should be added to the documentation.

mergify bot pushed a commit that referenced this issue Aug 10, 2021
…lient (#15893)

When an app client is created, it receives the name of the identity provider as a string.
During the deployment, the identity provider must be created first, then the app client can be created (because it references the identity provider).
Due to the fact that the reference is passed as a string, CDK can't add the dependency between the identity provider and the app client automatically. Therefore, `addDependency` must be called manually when both constructs are created in the same stack.

The missing dependency was reported two times in the last weeks (issue #15850 and #15692). Because of that I would propose to add this behaviour in the readme.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@nija-at
Copy link
Contributor

nija-at commented Aug 12, 2021

I've re-opened the original issue - #15692

Closing this as duplicate.

@nija-at nija-at closed this as completed Aug 12, 2021
@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

@nija-at nija-at reopened this Aug 12, 2021
@nija-at
Copy link
Contributor

nija-at commented Aug 12, 2021

I take my previous comment back. While they do look the same, it seems they're slightly different issues.

If both the user pool identity provider and client are associated with the same user pool, they will depend on each other.

@revmischa - can you provide the snippet of the CloudFormation template that gets synthesized, specifically the resources of type AWS::Cognito::UserPoolIdentityProvider?

@nija-at nija-at added the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label Aug 12, 2021
@revmischa
Copy link
Contributor Author

I think webClient.node.addDependency(provider) was what I needed, haven't had any issues since then. Thanks for the help!

@nija-at nija-at closed this as completed Aug 12, 2021
@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

hollanddd pushed a commit to hollanddd/aws-cdk that referenced this issue Aug 26, 2021
…lient (aws#15893)

When an app client is created, it receives the name of the identity provider as a string.
During the deployment, the identity provider must be created first, then the app client can be created (because it references the identity provider).
Due to the fact that the reference is passed as a string, CDK can't add the dependency between the identity provider and the app client automatically. Therefore, `addDependency` must be called manually when both constructs are created in the same stack.

The missing dependency was reported two times in the last weeks (issue aws#15850 and aws#15692). Because of that I would propose to add this behaviour in the readme.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
david-doyle-as24 pushed a commit to david-doyle-as24/aws-cdk that referenced this issue Sep 7, 2021
…lient (aws#15893)

When an app client is created, it receives the name of the identity provider as a string.
During the deployment, the identity provider must be created first, then the app client can be created (because it references the identity provider).
Due to the fact that the reference is passed as a string, CDK can't add the dependency between the identity provider and the app client automatically. Therefore, `addDependency` must be called manually when both constructs are created in the same stack.

The missing dependency was reported two times in the last weeks (issue aws#15850 and aws#15692). Because of that I would propose to add this behaviour in the readme.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-cognito Related to Amazon Cognito bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days.
Projects
None yet
Development

No branches or pull requests

3 participants