3

After using Cognito for a few months, some users in a user pool have now lost the "email_verified" attribute. I can't understand how it is missing or how to recover.

Symptoms are:

  • Users can still login
  • User password can not change (eg via JS SDK - changePassword), produces error: "x-amzn-errormessage: Cannot reset password for the user as there is no registered/verified email or phone_number"
  • Getting the user attributes for the user with the list-users CLI shows the attribute is missing

    aws cognito-idp list-users --user-pool-id MYID-123 --query 'Users[?Username==`error@bla.com`].[*]'
    [
      [
        [
            "error@bla.com", 
            true, 
            "CONFIRMED", 
            1522127817.526, 
            1522127819.369, 
            [
                {
                    "Name": "sub", 
                    "Value": "123123123341241238"
                }, 
                {
                    "Name": "email", 
                    "Value": "bla@bla.com"
                }
            ]
         ]
      ]
    ]
    

    vs. one with the attribute in place

    aws cognito-idp list-users --user-pool-id MYID-123 --query 'Users[?Username==`bla@bla.com`].[*]'
    [
      [
        [
            "bla@bla.com", 
            true, 
            "CONFIRMED", 
            1524048734.588, 
            1524048737.777, 
            [
                {
                    "Name": "sub", 
                    "Value": "1231231231231235"
                }, 
                {
                    "Name": "email_verified", 
                    "Value": "true"
                }, 
                {
                    "Name": "email", 
                    "Value": "bla@bla.com"
                }
            ]
          ]
       ]
     ]
    

If I try deleting the attribute (with enough permissions), it fails - as one would expect - explaining it is not mutable.

aws cognito-idp admin-delete-user-attributes --user-pool-id MYID-123 --username test2@test.com --user-attribute-names email_verified

An error occurred (InvalidParameterException) when calling the AdminDeleteUserAttributes operation: Cannot modify the non-mutable attribute email_verified
Efren
  • 4,003
  • 4
  • 33
  • 75

2 Answers2

3

I can not find the cause for this problem, other than blaming AWS Cognito.

A workaround/hack/patch is to add the attribute back, this time, the non-mutable check is not a problem

aws cognito-idp admin-update-user-attributes --user-pool-id MYID-123 --username error@bla.com --user-attributes Name=email_verified,Value=true

And now the user has the attribute again and I can reset the password.

Efren
  • 4,003
  • 4
  • 33
  • 75
  • Is there another user with the email address with email_verified set to true? That is are there 2 users with the same email address, one with email_verified = false and one with email_verified = true? – Brian Winant Aug 08 '18 at 07:39
  • Yes, as mentioned in the example in the question "one with the attribute in place" – Efren Aug 08 '18 at 23:13
  • Clarification: there are users with `email_verified = true` but they don't have the same email address as ones that have `email_verified = false` or missing. Now after these last months, the `email_verified` attribute was set to `false` again in the same problematic users. – Efren Jan 08 '19 at 02:15
0

If there are 2 users with same email address, and email_verified is true for one and not the other, it is possible it is an issue with your client code.

When you call confirmRegistration the first parameter is the confirmation code and the second is a boolean: forceAliasCreation. If set to true, then if a user already exists with the email address that is being used to register with, the new user "steals" the email address of the existing user.

It's not obvious this is a problem cause the Cognito API docs show examples of confirmRegistration with forceAliasCreation as true and not explaining what the parameter does (https://github.com/aws-amplify/amplify-js/tree/master/packages/amazon-cognito-identity-js - Use Case 2, assuming you are using JS). We ran into this problem with our app and this was the culprit.

Brian Winant
  • 2,915
  • 15
  • 17
  • Thanks I'll have a look. Apologies for the other reply it's not exactly like this, since instead of being false by "stealing" , the attribute actually disappeared. – Efren Aug 09 '18 at 06:45