-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Getting Error "There is already a signed in user" when trying to log in user who's already signed in #13813
Comments
Hello, @alaahafez20 and thanks for opening this issue. This is expected behavior in v6 of Amplify when trying to log the currently signed-in user. Can you share a little more about what you're trying to do by logging the user in v6? Would the |
Hello, @alaahafez20 In v5 we have In v6 we have Example snippet:
|
@cwomack The |
@alaahafez20, I'm not quite sure what the use case/context here is when you say that you're trying to "log in the currently signed-in user". Can you clarify what the "conditions that differ from the initial sign-in process" means? Are you looking to require a second sign-in before completing some type of CRUD operation or action from a user? Do you have any sample code from v5 where this was being done? Thanks. |
@cwomack, We have implemented a two-tier authentication system for users: "limited" and "unlimited." Currently, before sign-in, we send a request to our database to update the user's state (e.g., to "limited"). During the Cognito Lambda function execution, we retrieve the user's data from our database. Based on this data, we either log the user in immediately if their status is "limited" or initiate an OTP process if their status is "unlimited." Additionally, there is a requirement for users to be able to upgrade from a "limited" session to an "unlimited" session without needing to log out. |
@alaahafez20, appreciate the response and additional context here. It sounds like this is essentially a workaround for getting a mid-session MFA/OTP request for users that are already signed in (as captured in issues #6676 and #11447), which is something that isn't supported by Cognito at this point. This seems like this is not only a feature request (which I'll update the issue to), but also a version parity difference between v5 and v6 of Amplify. To be clear, it's not something that we documented support for in v5. Nonetheless, if it worked in v5 and doesn't in v6.... we'll review it internally as a feature request similar to the aforementioned "ad-hoc MFA request" issues. After digging into this further, it also seems that since you've already set up your Cognito lambdas tied to the Auth flow to handle the user's state that stored in the database... you might be able to do the following to achieve this in v6:
This will not only cause the OTP requirement to pop up again I believe, but also ensure that the refresh token from the previous session is revoked as well. Can you see if this works for your use case? |
This doesn't seem like the same issue as 6676 and 11447 - we also have this issue intermittently and it's for a regular credential auth with no MFA. The solution is to handle the error, signOut and then signIn? Seems like a workaround for something broken with v6, no? |
Before opening, please confirm:
JavaScript Framework
Next.js
Amplify APIs
Authentication
Amplify Version
v6
Amplify Categories
auth
Backend
None
Environment information
Describe the bug
In version 5, we could log a user in even if they were already signed in. However, in version 6, we're getting an error that prevents this. Is there a way to log a user in without requiring them to log out first?
Expected behavior
Expect to log a user in who's already signed in
Reproduction steps
Code Snippet
// Put your code below this line.
Log output
aws-exports.js
No response
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response
The text was updated successfully, but these errors were encountered: