Amplify-js: suppress prompt to verify contact information when verification not enabled

[tvald]

Describe the bug
I have configured a Cognito User Pool such that email address and phone number are neither collected from users, nor verified. Password resets may not be performed automatically, and instead users must contact an administrator.

When I wrap my application with withAuthenticator from amplify/ui-react, a user can successfully log in. However, the user is always prompted to verify their non-existent email and phone number, like so:

This screen should be automatically suppressed when verification is turned off, or when neither an email address nor phone number field is available for an account. (Or perhaps some other heuristic is suitable.)

At the very least, I should be able to configure amplify/ui-react to always suppress this screen.

To Reproduce
Steps to reproduce the behavior:

1. Configure a Cognito Pool to not require email / phone and not verify contact methods. Disable automatic password resets.
2. Wrap a react app in withAuthenticator()
3. Log in
4. See page prompting for verification of non-existent contact methods.

Expected behavior
Skip prompt and proceed straight to app.

Code Snippet

const App = withAuthenticator(() => (
  <div>
    <AmplifySignOut />
    <h1>HELLO WORLD!</h1>
  </div>
))

What is Configured?
Cognito was configured through the AWS Console.

• If applicable, please provide your manual configuration example:
  { Auth: { region: 'XX-XXXX-X', userPoolId: 'XX-XXXX-X_abcd1234', userPoolWebClientId: 'a1b2c3d4e5f6g7h8i9j0k1l2m3', mandatorySignIn: true, cookieStorage: { domain: 'localhost', path: '/', expires: 365, secure: false // ONLY FOR LOCAL DEV }, authenticationFlowType: 'USER_SRP_AUTH', } }

[tvald]

fwiw, I ended up passing a state transition listener to withAuthenticator() that immediately bumped the AuthState from VerifyContact to SignedIn, as if the user had clicked on the "skip" button.

[linden-dg]

@tvald do you have a sample of the code you used? I'm trying to achieve the same thing.

[tvald]

import Auth from "@aws-amplify/auth";
import {
  AuthState,
  UI_AUTH_CHANNEL,
  AUTH_STATE_CHANGE_EVENT,
} from "@aws-amplify/ui-components";
import { Hub } from "@aws-amplify/core";
import { withAuthenticator } from "@aws-amplify/ui-react";

const handleAuthStateChange = async (nextAuthState, data) => {
  if (nextAuthState === AuthState.VerifyContact) {
    Hub.dispatch(UI_AUTH_CHANNEL, {
      event: AUTH_STATE_CHANGE_EVENT,
      message: AuthState.SignedIn,
      data: await Auth.currentAuthenticatedUser(),
    });
  }
};

const App = withAuthenticator(() => <h1>HELLO WORLD!</h1>, {
  handleAuthStateChange,
});

[disrael]

Uclusion - as it turns out this can be fixed from the grant side - you have to make sure email verification is included.

[alucio-echen]

Could this be a bug in how the response from cognito is being parsed? If you look at the response from Cognito the email_verified attribute has a value of "True" but on the line below (which is called by the verifiedContact method) it's checking for "true"

https://github.com/aws-amplify/amplify-js/blob/a047ce73/packages/auth/src/Auth.ts#L1934

When we retrieve the parsed attributes on the user object the value is set to false even though in the cognito response it's set to True.

[cnorthwood]

This has manifested itself fairly recently for me - we're seeing users go straight from signedIn to verifyContact after immediately signing in. We're working around it by forcing a full page reload after successful signed in to get the withAuthenticator in the same state. We can't just ignore verifyContact as that state is also used for changing passwords on first login.

[alucio-echen]

Could this be a bug in how the response from cognito is being parsed? If you look at the response from Cognito the email_verified attribute has a value of "True" but on the line below (which is called by the verifiedContact method) it's checking for "true"

https://github.com/aws-amplify/amplify-js/blob/a047ce73/packages/auth/src/Auth.ts#L1934

When we retrieve the parsed attributes on the user object the value is set to false even though in the cognito response it's set to True.

I can confirm that granting read rights to the attributes in cognito and changing the line above to recognize "True" resolves the issue.

[wduminy]

I can confirm that granting read rights to the attributes in cognito and changing the line above to recognize "True" resolves the issue.

I added email verified to readable list, then the UI worked as expected when logging in. I did not make any code changes.

[lkowalski-smartbusiness]

@wduminy You sir deserve a beer! You've saved me hours upon hours of investigation and fixed an extra bug on my side where I didn't "check" a custom attribute as readable and was wondering why it's not updating accordingly.. Pure joy!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.

[Maximaximum]

Just wanted to mention that, if you're using the amplify console to set up the backend and are having this issue, the proper name of the attribute is email_verified

    "userpoolClientReadAttributes": [
        "email",
         ...
        "email_verified" // <- this is important
    ],