Stale confirmed user with wrong email address
Dlozitskiy opened this issue · 3 comments
There is a scenario where user types wrong email address on initial sign up accidentally or intentionally.
This will create confirmed user in user pool. User won't be able to login using this email as he won't get access code, so the account will end up in limbo.
This account email address can potentially be a legitimate email for another user who will not be able to sign up getting "User Already Exists" exception.
I think the logic should be a bit more complex, similar to below:
a) check for a new signing up user if a user pool user with the same email already exists
b) if exists - verify if user pool user has email status is confirmed
c) if user pool user email status is not confirmer - delete user pool user and proceed with a new user sign up
d) update new user pool user email status to "confirmed" after first successful sign in
Hi Dlozitsky.
Thanks for mentioning this! Interesting problem.
I would like to autoconfirm users, otherwise users would get a separate confirmation mail with a code. They'd first have to enter that code to confirm, then try sign-in again and get another code to sign-in with. That takes away the smoothness of passwordless sign up/in.
However, setting emailVerfied to true in the preSignUp trigger is not per se necessary.
What do you think of this proposal:
- In the preSignUp trigger, set user to confirmed automatically, but not email verified
- Have a post authentication lambda set the email to verified (that lambda runs when the user was actually able to sign-in with the code that was sent to his/her mail address).
So then any user that has emailVerified=false has apparently never signed in. You can then solve the issue scenario as you propose, or maybe even have a batch job that you run monthly to delete users who were not able to sign-in within 7 days of account creation. I guess there's many ways in which developers may want to proceed in this case, so I'm not sure the standard solution here should include this functionality. I am convinced about not setting emailVerfied to true though, but do that only after successfull sign-in.
What do you think? Want to send a PR for it?
Please let me know. Otherwise I’ll go forward with that myself