Allow a user to fix phone_number attribute during signUp()

0

My cognito backed is set to require and confirm email and phone_number. In this case, Cognito will only send text messages to the given phone_number and depends on app logic to confirm the email address. However, during signUp(), the user can provide a valid but incorrect phone number (typo, landline, whatever) which must be corrected to complete the initial sign up. I don't see a way to let the user make corrections.

Calling signUp() again with a corrected value returns an error because the unconfirmed user has polluted the cognito table. User "already exists". I can't have the app updateAttributes() of a user that isn't confirmed since they couldn't generate authorization tokens.

What is the workflow here? Do I have to expose a lambda function that has the rights to delete unconfirmed users from the backend?

Edited by: namegoeshere on Mar 17, 2020 10:04 AM

已提問 5 年前檢視次數 826 次
2 個答案
0

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

已回答 5 年前
0

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

已回答 5 年前

您尚未登入。 登入 去張貼答案。

一個好的回答可以清楚地回答問題並提供建設性的意見回饋,同時有助於提問者的專業成長。

回答問題指南