Open oemer-aran opened 2 years ago
+1
Also have the same scenario with confirmation after redirection from email. Would be great if autoSignIn
is triggered in this case too.
+1
+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. In the signup page, when the user enter the phonenumber and clicks the signup button, an OTP will be sent to their phone and the field to enter OTP will appear on the screen. If the user enters the otp and submit it , he would be signedUp and also gets automatically signedIn as I have enabled the autosignIn. But , if he doesnt enter the OTP and reloads the Page, then he have to enter the phonenumber again and OTP will be sent to his phone and he will be prompted to enter the OTP. If the user enters the OTP , this time the autosignIn is not working.
Is there any solution to this issue?
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.
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 https://github.com/aws-amplify/amplify-js/issues/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 Feature Request
label if it's not a bug and not an existing feature from the Amplify side.
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
+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+
Hi folks!
I fixed this problem by calling Auth.signIn each 5 seconds.
await Auth.signUp({ username: this.email, password: this.password, attributes: { given_name: this.firstName, family_name: this.lastName, birthdate: this.dateOfBirth, } }) .then(() => { this.intervalId = setInterval(() => { Auth.signIn(this.email, this.password).then(data => { this.updateAuthState(data); }); }, 5000); }) .catch(async e => { await store.dispatch( "ui/setErrorMessage", `Error while creating account: ${e.message}` ); }); }
Because user and password are the correct one, you can call Auth.signIn as many times as you needed.
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.
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.
@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
useEffect(() => {
const storageListener = (event: StorageEvent) => {
if (event.key === "signUpConfirmation" && event.newValue) {
try {
const userConfirmEvent = confirmSignUpDecoder(event.newValue);
if (route === "confirmSignUp" && !userConfirmEvent.confirmed) {
confirmUser(userConfirmEvent);
}
} catch (error) {
console.error("Error processing signUpConfirmation data", error);
}
}
};
const confirmUser = async (confirmEvent: userConfirmationEvent) => {
let s: ConfirmSignUpOutput = {
isSignUpComplete: false,
nextStep: {
signUpStep: "DONE",
},
};
try {
s = await confirmSignUp({
username: confirmEvent.email,
confirmationCode: confirmEvent.code,
});
} catch (error) {
console.log("error confirming signup", error);
}
// User now confirmed, notify signupcode page it can be closed
localStorage.setItem(
"signUpConfirmation",
confirmSignUpEncoder({ ...confirmEvent, confirmed: true })
);
// Auto signin user
let t: SignInOutput = {
isSignedIn: false,
nextStep: {
signInStep: "DONE",
},
};
if (
s.nextStep.signUpStep === "COMPLETE_AUTO_SIGN_IN" ||
s.nextStep.signUpStep === "DONE"
) {
try {
t = await autoSignIn();
} catch (e) {
console.log("autoSignIn failed", e);
}
}
};
}, [router, route]);
A few notes:
I believe confirmSignUp
call requires user's email in the username param (I thought it would be the sub, as in CustomMessage Lambda example the Amplify encoding originally)
I'd like to understand how autoSignIn() works with the Authenticator. I'm using plain Authenticator UI without any low-level functions. There is useEffect that checks AuthenticatorRoute
to match confirmSignUp
state, and that magically works.
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:
ls ../xxx-api/amplify/\#current-cloud-backend/auth/xxx/assets/
index.html spinner.js style.css verify.js
It doesn't do much except makes a confirmSignUp API call in verify.js
function confirm() {
const urlParams = new URLSearchParams(window.location.search);
const encoded = urlParams.get('data');
const code = urlParams.get('code');
const decoded = JSON.parse(atob(encoded));
const { userName, redirectUrl, clientId, region } = decoded;
var params = {
ClientId: clientId,
ConfirmationCode: code,
Username: userName,
};
AWS.config.region = region;
var cognitoidentityserviceprovider = new AWS.CognitoIdentityServiceProvider();
cognitoidentityserviceprovider.confirmSignUp(params, function (err, data) {
if (err) {
if (err.message === 'User cannot be confirm. Current status is CONFIRMED') {
window.location.replace(redirectUrl);
}
} else {
window.location.replace(redirectUrl);
}
});
}
As you can see, "hosted" confirmation is using these params in confirmSignUp:
ClientId: clientId,
ConfirmationCode: code,
Username: userName, // sub
and for Authenticator UI I had to use a different set:
username: confirmEvent.email,
confirmationCode: confirmEvent.code,
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.
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.
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 Auth.confirmSignUp
function that has an option of autoSignIn
, which is independent of existing sessions and just works.
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/
And you can do some awesome things, like Magic Links or things like authentication via QR-Codes. It’s easy to implement – it’s called “custom challenges” within AWS Cognito. OK, easy if you know Cognito, Lambdas and understand the flows 😉 I used it for example to do an auto-login after the email was verified. It’s just one Lambda function away. OK, in this case, I needed three 😉 One for creating the magic link, one to verify it and another to determine if there is another challenge or the authentication was successful.
@brettstack which blog?
very disappointing that there is no movement in this topic
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/
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 confirmSignUp
is called, I get the expected response { isSignUpComplete: true, nextStep: {signUpStep: 'DONE'} }
, however any call to the client from generateClient()
in amplify v6 gives this error: 8069-503a136a0f5f1e58.js:1 NoValidAuthTokens: No federated jwt
. This is from the same session, in the same tab. Perhaps it is because autoSignIn
does not work in amplify v6? Or because this is a next.js app? Regardless, I will need to get a workaround in place that passes username and password through and calls signIn
after confirmSignUp
.
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:
NotAuthorizedException: Logins don't match
)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?
// TODO(Eslint): can this be refactored not using `let` on exported member?
// eslint-disable-next-line import/no-mutable-exports
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 Auth.signUp
only for validation now (e.g. if the user already exists). The confirmation will be very custom, as I will explain now.
After PreSignUp lambda was successful, we autoConfirm
the user. This ensures that the PostConfirmationLambda is triggered. At this point the user is already created, which lets us use some Cognito admin actions.
In the PostConfirmationLambda we then call AdminSetUserPassword
with a random generated password (like a code). We then call AdminCreateUser
with MessageAction: "RESEND"
to trigger the email including the generated password using CustomEmailSenderLamda.
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:
Since the user enters his password AFTER receiving the email, we can immediately log him in with the new password. No autoSignIn
needed.
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.
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
Auth.signUp
only for validation now (e.g. if the user already exists). The confirmation will be very custom, as I will explain now.After PreSignUp lambda was successful, we
autoConfirm
the user. This ensures that the PostConfirmationLambda is triggered. At this point the user is already created, which lets us use some Cognito admin actions.In the PostConfirmationLambda we then call
AdminSetUserPassword
with a random generated password (like a code). We then callAdminCreateUser
withMessageAction: "RESEND"
to trigger the email including the generated password using CustomEmailSenderLamda.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: Since the user enters his password AFTER receiving the email, we can immediately log him in with the new password. No
autoSignIn
needed.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 aws-amplify/auth
doesn't consider a user authenticated once they have signed up with signUp()
. In a custom implementation, one might store a user's email and password but disallow them from using the rest of the app until they have verified their email. However, although Cognito stores the user on their backend, they don't expose that through aws-amplify/auth
for one's app to make that decision yourself. You need to keep calling signUp()
and handle the rest based on the (failed/unauthenticated) response from that each time.
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
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: https://github.com/aws-amplify/amplify-js/issues/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