amplify-js: autoSignIn doesn't work if Auth.confirmSignUp was called in a different session than Auth.signUp

1+

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:

1. User signs up on app.
2. User receives email confirmation code, but does not use it and exists the app’s browser tab.
3. User reopens app and signs in, as they already have an account (unconfirmed).
4. User is sent a new email confirmation code.
5. User confirms code on app, which results in an autoSignIn_Failure.
6. User now has to reinput their username and password and sign in again to get a session.

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.

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.

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.

@brettstack which blog?

very disappointing that there is no movement in this topic

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.

My autoSignin is not working even in the same tab

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

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!

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:

1. 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)

2. 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.

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);