Comments (8)
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:
- copy the new user pool's lambda trigger configuration to your pre-existing pool
- 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, anIUserPool
). You can only use a user pool that you create in the same stack (then it is aUserPool
, not anIUserPool
).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:
- copy the new user pool's lambda trigger configuration to your pre-existing pool
- 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
andIUserPoolClient
but type asserting it toany
. 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:
-
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?. -
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?
-
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
andIUserPoolClient
but type asserting it toany
. 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.
Related Issues (20)
- Passwordless.configureFromAmplify() no longer works with the latest version of Amplify (v6)
- Type error in Verifying FIDO2 Challenge Response HOT 6
- Usage of stepUpAuthenticationWithSmsOtp in plain web. HOT 5
- Feature request: HOT 1
- Amplify cli end-to-end example HOT 5
- [Question] Using Fido2 credentials for non-signin challenges HOT 1
- Prominently mention JWT/localStorage issues in FAQ -- Avoid JWT? HOT 6
- signInStatus is 'NOT_SIGNED_IN' during refresh of token HOT 3
- Dependency issue while implementing this tutorial HOT 4
- FrontEnd Shows "Unexpected End of JSON Input" HOT 8
- The example don't work corrrectly with Windows Hello through PIN authentication HOT 17
- [Feature] Provide a python package HOT 1
- Resetting state HOT 4
- Magic Link Metadata Storage HOT 8
- ReferenceError: debug is not defined HOT 1
- [Bug] Magic link abuse by authorized user HOT 9
- [Feature Request] Add OTP SMS authentication HOT 5
- Can we load logo from assets folder locally HOT 4
- Prevent users from self-edit attributes HOT 6
- [Need Help] - No "exports" main defined in ../node_modules/amazon-cognito-passwordless-auth/package.json HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from amazon-cognito-passwordless-auth.