Type 'IUserPool' is missing the following properties from type 'UserPool' about amazon-cognito-passwordless-auth HOT 8 CLOSED

We should potentially support this as a feature actually .... it's a bit tedious now to use an existing User Pool:

Let the solution create its own user pool (that you will not use) and after it deployed you:

1. copy the new user pool's lambda trigger configuration to your pre-existing pool
2. change the authorizer of the the FIDO2 API to point to your pre-existing user pool (only relevant if you want to use FIDO2)

If you are handy in messing with CDK and TypeScript you can maybe try passing in an IUserPool and IUserPoolClient but type asserting it to any. Potentially deployment will actually work then, without creating the new user pool. The API authorizer would be set to the right UserPool automatically, but you'd still have to manually set the lambda trigger config. But you could do that in a custom resource might you want to automate it fully.

from amazon-cognito-passwordless-auth.

Hi @myevit

The reason is you can't use an existing user pool like that (using the fromUserPoolId method gives you a pointer to an existing user pool, an IUserPool). You can only use a user pool that you create in the same stack (then it is a UserPool, not an IUserPool).

Now why did we build it like that you may ask :) Because CloudFormation doesn't support adding Lambda trigger config (for custom auth) to an existing user pool. You must provide it as part of creating the User Pool.

We could potentially add support for your case by skipping the Lambda trigger adding for existing user pools. You'd have to do that yourself then. You could update an existing User Pool with some additional coding (CFN custom resource). If there is demand for it maybe we can add it to this solution. But it's a always bit hairy to step out of the normal CloudFormation flow, so am inclined to only document how to do it should you want it.

from amazon-cognito-passwordless-auth.

Thank you for your reply,
It does make sense. But given that one doesn't want to mess with userPool if it is in use by other apps, that app stack can't be used directly. I guess at this point it's easier and faster just pin lambda, created by CF to existing pool and make the app manually.
On a side note: if I am trying to use end-to-end example I have an error: 'rror: Stack name must match the regular expression: /^[A-Za-z][A-Za-z0-9-]*$/, got 'mystackname Env file: CDK_STACK_NAME=mystackname

from amazon-cognito-passwordless-auth.

On windows? Windows line ending potentially the issue ...

from amazon-cognito-passwordless-auth.

Thanks! That must be it.

from amazon-cognito-passwordless-auth.

Hi @myevit

The reason is you can't use an existing user pool like that (using the fromUserPoolId method gives you a pointer to an existing user pool, an IUserPool). You can only use a user pool that you create in the same stack (then it is a UserPool, not an IUserPool).

Now why did we build it like that you may ask :) Because CloudFormation doesn't support adding Lambda trigger config (for custom auth) to an existing user pool. You must provide it as part of creating the User Pool.

We could potentially add support for your case by skipping the Lambda trigger adding for existing user pools. You'd have to do that yourself then. You could update an existing User Pool with some additional coding (CFN custom resource). If there is demand for it maybe we can add it to this solution. But it's a always bit hairy to step out of the normal CloudFormation flow, so am inclined to only document how to do it should you want it.

Hi, junior dev here. I'm facing the exact same issue, I would like to use an existing user pool that was not created in the stack. Would you then recommend to manually configure lambda to the existing user pool? Is there a recommended approach to achieve this? Thanks in advance!

from amazon-cognito-passwordless-auth.

We should potentially support this as a feature actually .... it's a bit tedious now to use an existing User Pool:

Let the solution create its own user pool (that you will not use) and after it deployed you:

1. copy the new user pool's lambda trigger configuration to your pre-existing pool
2. change the authorizer of the the FIDO2 API to point to your pre-existing user pool (only relevant if you want to use FIDO2)

If you are handy in messing with CDK and TypeScript you can maybe try passing in an IUserPool and IUserPoolClient but type asserting it to any. Potentially deployment will actually work then, without creating the new user pool. The API authorizer would be set to the right UserPool automatically, but you'd still have to manually set the lambda trigger config. But you could do that in a custom resource might you want to automate it fully.

Firstly, thank you for your tremendous work on the library, it's great! (I know this issue is closed, so maybe I should open a new issue?)

The manual configuration of lambda triggers to the existing user pool, and the creation of the authorizer for the API approach, worked perfectly. The TypeScript approach not so much, couldn't make it work that way.

I'd like to discuss a few issues and gather your insights:

1. Removing Magic Links: Upon removing the magic link from the Passwordless constructor, there is an issue with this line user.node.addDependency(userPool.node.findChild("PreSignUpCognito")); in the CDK code, and the pre-sign-in Lambda function isn't created. This omission impacts non-library related functionalities, such as registration via Amplify's Auth.signUp. Is this behaviour by design?.

2. Amplify Integration: Given the library's design to complement Amplify, I've noticed the potential necessity to transition from the traditional Auth.signIn to the authenticateWithSRP property provided by the usePasswordless hook. Failing to do so seems to introduce synchronization discrepancies with Amplify, particularly with the signInStatus not updating promptly. I'm considering replacing Amplify's Auth class entirely with the usePasswordless hook, would you recommend prioritizing the library as the single source of truth over Amplify (to avoid sync issues), or is there a feasible approach to synchronizing both without issues?

3. Prototype to Production: I've developed a prototype app to simulate the integration of passwordless authentication using the library, aiming to replicate my app's authentication flow. To ensure a smooth transition and minimize user disruption, I considered testing with a second user pool. However, this approach seems to conflict with Amplify, potentially requiring the removal and reimportation of authentication configurations, which is not feasible in my case. Could you recommend a strategy for safely testing these changes without affecting the current user experience?.

Thanks in advance!

from amazon-cognito-passwordless-auth.

Hi mate!

About 1: Where is that user.node.addDependency(userPool.node.findChild("PreSignUpCognito")); code actually ...? Not in this repo is it? You are adding user programmatically win CDK? If you don't support magic links, you don't need the PreSignUp logic from this library. In that case there is no need per se to auto confirm users, which is why it's excluded then. But you can still add a PreSignUp trigger yourself if you want.

About 2: This lib should work with Amplify and if there's sync issues/discrepancies I'd like to get to the bottom of it. Please show us a case to reproduce. You're the 2nd user to mention the cooperation with Amplify isn't flawless, and that's a bug we should solve. Having said that, if you don't use Amplify otherwise, then yes you might just use the library here, and not Amplify at all. In fact, that's how I use it! Part of the reason this lib implements the Cognito API itself, is to be a lean and mean alternative to Amplify Auth. It has less features of course, but for my use cases it has all that I need (e.g. sign in, sign out, token refresh). A notable thing that is in Amplify Auth and not in this lib here, is OAuth2/SAML federation.

About 3: I would expect that you can add this lib (manually) to your existing user pool, and that Amplify wouldn't need to know about it, or be changed whatsoever?

We should potentially support this as a feature actually .... it's a bit tedious now to use an existing User Pool:

Let the solution create its own user pool (that you will not use) and after it deployed you:

1. copy the new user pool's lambda trigger configuration to your pre-existing pool

2. change the authorizer of the the FIDO2 API to point to your pre-existing user pool (only relevant if you want to use FIDO2)

If you are handy in messing with CDK and TypeScript you can maybe try passing in an IUserPool and IUserPoolClient but type asserting it to any. Potentially deployment will actually work then, without creating the new user pool. The API authorizer would be set to the right UserPool automatically, but you'd still have to manually set the lambda trigger config. But you could do that in a custom resource might you want to automate it fully.

What goes wrong in your case?

It would probably be best to open a separate ticket! Thanks!

from amazon-cognito-passwordless-auth.