Hi;
Can you confirm the email-verification step is done explicitely after the signup promise resolution; in a non blocking way ?
That's important to us, as we modified the signup, which now includes an internal db transaction to create a user in our database. This user is not "visible" outside of the transaction before it resolves; and later we might "find" this user before sending the verification email (we also override the email send).
r
rp_st
06/28/2023, 12:46 PM
hey @Chimanos yes that is correct. For login methods which do not already verify emails, first the sign up and session creation process is completed, and only after that the user is sent into the email verification flow.
For other login methods like sign in with google, passwordless, where the email is already verified during user creation, we first create the user -> mark their email as verified -> create a session.
c
Chimanos
06/28/2023, 12:47 PM
Alright, thanks 🙂
Chimanos
06/28/2023, 12:48 PM
I gave a look into userContext (to pass the (internal database) user from signup to email-verification recipe); but I confess I didn't understand anything from there lol.
I might stick to re-find the user for now
r
rp_st
06/28/2023, 12:48 PM
the user context is per API call
rp_st
06/28/2023, 12:49 PM
since the email verification is a different API call than the sign up one, the userContext modification is lost
SuperTokens is an open source authentication solution offering features like: Different types of login: Email / password, Passwordless (OTP or Magic link based).