-
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
autoSignIn doesn't work if Auth.confirmSignUp was called in a different session than Auth.signUp #10225
Comments
+1 |
Also have the same scenario with confirmation after redirection from email. Would be great if |
+1 |
1 similar comment
+1 |
Hey @oemer-sellwerk 👋 . I was able to reproduce the issue by signing up a user in one tab and then confirming their code in a different tab (which is likely what happens if you're sending an emailed link). This results in the "autoSignIn_failure" error being returned from Hub. I'm going to review this with the team and get back to you on next steps for this issue, but let me know if there's any additional context/updates that happen in the mean time. |
After discussing this with the team, we're going to label this as a feature request. Currently, it's not a default behavior for Cognito to utilize a redirect link in emails for a new user to sign up. |
A potential workaround to autoSignIn on another tab might be to setup a storage event listener that checks if the cognito access, id, and/or refresh tokens have been stored locally. The storage event listener will trigger if localStrage has changed from another page on the same domain, so the other tab will reload or redirect, whatever you need it to do to update state and login/logout. something similar to this const storageListener = (event) => {
console.log(event);
if (
event.key?.includes("CognitoIdentityServiceProvider") &&
event.oldValue === null &&
event.newValue !== null
) {
// handle tokens being added (login) or removed (logout)
window.location.reload();
}
};
window.addEventListener("storage", storageListener);
// cleanup
window.removeEventListener("storage", storageListener); |
+1 |
Any solutions on this issue? |
I have made a Phonenumber,OTP signup and signIn in my app. Is there any solution to this issue? |
Hi @cwomack , just wanted to reference this being classified as a Feature Request - given that this is happening for the default option of emailed confirmation codes as well as the other option of emailed links, I do believe this is essential for this to be fixed by the Cognito team and is not just a new feature to be added. It disrupts the user flow that the autoSignIn feature is meant to solve. To reiterate the steps to reproduce the issue and show that they are consistent with the default options of Cognito's verification system, reference below:
Since it has been over 3 years since this issue was initially opened on #2562 , I and many others would love if this issue could be resolved. We appreciate any help that you can give. |
+1 |
Still an issue |
@noahfaro, appreciate the detailed reply and reproduction steps. We use the I reviewed this issue again today with the team internally and it's now added to a list of Feature Requests that are blocked by and need to be reviewed with the Cognito Service team (hence the new labels). We'll update this issue with any progress as it comes. |
+1 |
2 similar comments
+1 |
+1 |
Please don't endlessly post +1 without any context as this notifies everybody, like me, that are just silently subscribed to the issue. You can use the thumbs up reaction on the first post to show support for it. Though I would assume that there's no priority from thumbs ups or +1 messages. |
1+ |
This is misleading and has nothing to do with the actual issue being reported. |
+1 |
Has anyone had success with this in the v6 release? I just got hit by it. I've created a link that auto populates the code but it opens in another tab so has this redirect failure. |
@chrisbonifacio, thank you. It's a great idea, and it is working well. I used a CustomMessage lambda that generates a confirmation link with a code, but instead of using hacky "backend" to run confirmation API call (I explain below why its hacky and not functional), I've added a simple page that parses URL, stores code and email in local storage. Auth page is using it to continue with the confirmation and signing in user. URL: /signupcode?data=encodedUserInfor=&code=123123 And then in Auth component, I do this
A few notes:
Finally, to add even more confusion with Authenticator and Auth modules, it is not clear why Amplify has the custom message functionality with a confirmation link in the form of this junky code:
It doesn't do much except makes a confirmSignUp API call in
As you can see, "hosted" confirmation is using these params in confirmSignUp:
and for Authenticator UI I had to use a different set:
It would be great if Amplify had some documentation about these nuances. By the way, all that custom messaging is broken anyway; there is an issue somewhere that the cli is not deploying these files correctly. The Amplify team could clean it up to avoid confusing developers with this half-baked option. |
These workarounds are tedious and only work when the initial tab is still open. But what if the user just registered and opens his email on another device or the next day? Then the tab won't be open. We need a dedicated solution from the amplify team. This feature is essential for any smooth registration flow. If possible I would suggest an We are currently thinking of abandoning Cognito and look for other options, primarily because of this issue. Including other similar tickets, it's been more than 3 years. |
This is an absolutely crucial feature. Looking at critical optimizations of our registration flow, using amplify is a major disadvantage. We do loose a lot of potential customers with this break in user-flow. All our competition can provide a seamless flow. It is just what users expect to work. This problem costs us money. Please do fix this now! |
This blog hints at combining Magic Links with the verification flow to achieve this. I haven't tried it myself, but it sounds interesting. https://www.zeile7.de/insight/user-authentication-with-aws-cognito/
|
@brettstack which blog? very disappointing that there is no movement in this topic |
This is great write up :) When you see a blog about cognito listing shortcoming upfront and mentioning bad, ugly and worst 20 times combined - you know its good Lol |
If there is any need to move a session token around, we could send this over the email link for the next tab, the amplify team only needs to expose the session token on ConfirmSignUpOutput and allow us to pass it on autoSignIn as a parameter. |
My autoSignin is not working even in the same tab |
I also cannot get autoSignIn to work at all, even in the same session, same tab. After |
For us, autoSignIn doesn't work in the same tab either. Furthermore, it fails inconsistently, sometimes working, sometimes failing. Repeating the exact same steps in the exact same tab, no page (re)loads of any sort. Steps are the following:
But then again, I just saw the brilliant way state is handled in the auth package jesus christ and it makes me wonder how anyone ever expected this to work exactly? Doesn't it make sense that the eslint rule wasn't created because someone got bored, but for an actual reason?
There's even a TODO left (kudos to the author of the comment) |
So after several years, we did "unfortnately" create a custom auth flow with Cognito admin actions. This missing feature was one of the main reasons. We use After PreSignUp lambda was successful, we In the PostConfirmationLambda we then call After the user clicks on the email button link, we get the code from the URL and try to log him in. Then we show a Set Password Form where he can set his own password. Now comes the part with auto sign in: Ofc, this is just a simplified description, but you should get the gist of it. I don't like the fact we had to do so much on our own to achieve a basic auth flow, but it seems to work very well for some weeks now. Hopefully amplify team will find some time to fix this in the core. |
I have implemented a similar approach based of resetting the preset password, this workaround is cumbersome but strictly necessary to guarantee a competitive parity even while using cognito... |
I'm running into a similar issue. Sad to see it's been so many years without a solution that doesn't involve a bloated workaround. The way I understand the problem is that |
same problem here |
I am surprised this is still an issue after 2 years. Has anyone implemented autoSignIn recently? |
the way it works and its proper implementation is also hardly discussed in the documentation |
I have. I can confirm it doesn't work with email verification links. You have to have the user enter their code in the same browser tab as the sign up. |
As a workaround I ended up storing the sign in details to a React Ref, then reuse them after const detailsRef = useRef<SignInInput>() ... return (
<Authenticator
services={{
async handleSignIn(formData) {
detailsRef.current = formData
return signIn(formData)
},
async handleConfirmSignUp(formData) {
const confirmSignupResult = await confirmSignUp({...formData, options: {autoSignIn: true}})
await signIn(detailsRef.current)
return confirmSignupResult
},
}} Which will cause the An 'official' fix would still be very welcome though. |
I am also dealing with this issue. Here are my steps to reproduce (in the same browser / tab):
We updated the We are using:
Also, FWIW -- I would review the security implications when considering @CraigHarley's solution. You typically want to avoid storing credentials on the client side. |
Before opening, please confirm:
JavaScript Framework
Vue
Amplify APIs
Authentication
Amplify Categories
auth
Environment information
Describe the bug
Using the
autoSignIn
option withAuth.signUp
only works, whenAuth.confirmSignUp
is called in the same tab/session. This can lead to very bad UX during the registration process. An example where this can happen is when you have a confirmation email. The email can have a button which redirects the user to the confirmation page to enter the confirmation code. The page will be loaded in a new session/tab, which will makeautoSignIn
fail.If the user remains in the same tab/session after calling
Auth.signUp
and callsAuth.confirmSignUp
it works as expectedI took a look into the code already, and the way it's implemented it also makes sense.
handleAutoSign
is called in theAuth.signUp
function. This functions setsautoSignInInitiated
to true. However, since Auth is loaded from scratch if you click on the email link/open a new session,autoSignInInitiated
is obviously stillfalse
. IfautoSignInitiated
is false, whenAuth.confirmSignUp
is called, the Hub returns the error:autoSignIn_failure
.Suggestion, if technically possible:
Logically it makes more sense to me to put the
autoSignIn
option in theAuth.confirmSignUp
function (and notAuth.signUp
). The response can then contain the user and a Hub event wouldn't be required anymore.P.S.: Not sure if this is a bug or intended. But since the
autoSignIn
feature has very little benefit and inconsistent behaviour as it is right now, I sort it more bug category.This is a follow up to: #6320
Expected behaviour
autoSignIn
event.Reproduction steps
Auth.signUp
andautoSignIn: { enabled: true }
(e.g. on/register page
)/register/confirm?username=my@email.de&code=492994
Auth.confirmSignUp
using the URL params from 2.autoSignIn_failure
Code Snippet
Log output
aws-exports.js
No response
Manual configuration
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: