Allow a user to fix phone_number attribute during signUp()

Reading over the documentation, uses cases, and rampant and varied complaining about Cognito and the quality of the Amplify library on github this is clearly a design oversight.

The only way forward that I can see is to mis-use the Cognito interface and cover the deficiencies with lambda triggers...

Edited by: namegoeshere on Mar 21, 2020 2:24 AM

Can't use lambda triggers to do work because you can't return arbitrary status messages to caller...

Can't require MFA because the only ways to recover from a typo'd 'phone_number' during signUp() are writing a lambda with administrative rights and exposing it to arbitrary anonymous users or having customers use the batphone...

Can't use the user pool's username sign-in type and guarantee e-mail uniqueness in the table. Individuals would have to know to keep creating new usernames until they typed 'phone_number' correctly. A zombie account per typo. Also, unnecessary freedom to make additional accounts at will with *_validated attribute booleans rotating state with various logins in the database. If validation states are used in your interface that could be a mess. I prefer to save the user from themselves and keep the database's signal to noise ratio high for when real administrative work comes up...

Therefore, can't follow advice documented by Amazon to sign up with both e-mail and phone and expect automatic validation of phone number followed by app enforced validation of e-mail to function. It's no good.

Given all of the above, my solution:

User pool setup
*Configure database for e-mail address sign in. Enforces uniqueness in the pool.
*Leave all attributes requirements unchecked.
*Make MFA optional.
*Enable SMS text message for second factor.
*Account recovery is email only. Not really relevant to the solution. Choose what you will.
*Verify email attribute only.

App flow
1.) Collect 'username', 'email', 'password', 'phone_number'.
2.) signUp('username','email','password'). Hold 'phone_number' for later. Email verification code goes out.
3.) confirmSignUp('code'). Can return to 1.) at will until this step works.
4.) signIn('username','password') in the background to get 'user' object. No prompts required, no MFA yet.
5.) updateUserAttribute('user','phone_number'). Verification code goes out.
6.) verifyCurrentUserAttributeSubmit('code'). Can repeat 5.) and 6.) until it's right.
7.) enableSMS(). To ensure all future logins use MFA texts.

Downside of this solution is that a nefarious actor can pollute the user pool with many accounts in the unconfirmed state. An affected new user would see their account exists but a forgot password flow would sort it out. Automated periodic garbage collection would minimize those odd occurrences.

Edited by: namegoeshere on Mar 24, 2020 2:19 AM