https://supertokens.com/ logo
Join Discord
Powered by
Hey, I'm looking at doing email verification but I...
# support-questions-legacy
a
Hey, I'm looking at doing email verification but I store a username instead of an email. I bit of a complicated flow. We are wanting to be anonymous - hence the interesting use-case. But I want the flow to be: - Send verification to a specific email - User verifies the code within our app - User has a username automatically generated for them that we have stored in supertokens - User is able to then update their username / set a password if they chose (but we don't require them to)
r
hey @Alex
> Send verification to a specific email Where and how do you capture the user's email?
a
In the app we ask for it - but we only want to use it for verification - not long-term storage
r
ahh i see. So that's sort of independent to their auth credentials?
a
Yes. We want to verify where they work. We want to create a username immediately for them after verifying
r
So during sign up, you would ask them for their email and a password, verify that email, and then replace their email with an auto generated username?
a
First ask for their email, verify their email. Then we want to log them in with an auto generated username. Finally they are presented option to change their username + create a password
So password is not required
r
got it. So you can do the following: - Create a user with an email and a fake (predefined) password. This will make a session for them as well. - Follow the usual email verification flow that SuperTokens has. - Post email verification, you ask the user for a password and replace the fake password with the one they entered (if they want to set a password) - Autogenerate a username and replace the email in the core with the username + mark the userId + username combination as verified in the email verification recipe. You would also need to change the default validation logic for the email input to allow for emails + a username. --------------- We have an example app that does some part of this flow - specifically creates a user with a fake password, verifies their email, then asks the user to set a password - so you can take inspiration from that to further modify the flow to achieve what you want. Here is the link to the example app: https://github.com/supertokens/supertokens-auth-react/tree/master/examples/with-emailverification-then-password-thirdpartyemailpassword
a
Wow. This is brilliant.
r
i think you use a python backend, but the example app has a node backend. That being said, the logic remains the same.
The example app also overrides the sign in API to disallow use of the fake password - im not sure if you want to do that.. depending on your desired sign in flow + security needs.
a
How are verifications stored in the DB for passwordless flows? I'd like to clear out via a job those who don't verify after the 15 minutes expiration of the code
r
When you say passwordless flow, are you referring to the email verification part of it?
a
Yes
Oh I see
I won't use passwordless
r
right.
so you can set the email verification token lifetime in supertokens and that will auto clear
a
Will that clear the row with the email?
r
yes.
a
Amazing
r
but it won't delete the user
a
What's the difference?
r
which is what i guess you want to do
a
(difference between user and email)
r
well, here it;s the diff between a user and their email verificaiton info. The email verificaiton info will get cleared out on it's own if the token is not consumed, but the user entry will stay. You can remove the user entry yourself after certain amount of time via a cronjob using the deleteUser function.
Actually, I just thought of another way to achieve this flow without actually creating a user in the first place and creating the user only after they have gone through the email verification flow. This might work better for you:
a
(looking at the supertokens-pythong sdk) Is there an exposed way to call delete user directly within my python code? (such as supertokens = int(), supertokens.deleteUser) Or do I have to go through the exposed REST api?
r
there is a function for delete user
> Actually, I just thought of another way to achieve this flow without actually creating a user in the first place and creating the user only after they have gone through the email verification flow. This might work better for you: - Start by asking the user for their email. Send that to a custom backend API you make. In that backend API, create a new supertokens session such that the userId = input email (yes, you can make a session for a user that doesn't exist in supertokens - all thats needed is some ID). Also, add the emailverification required claim to the session. - When doing emailverification.init on the backend, provide a function to it. It should be called 
get_email_for_user_id
. This function takes the user_id as input and is called during the email verification APIs. In our case, since we have created a session such that the email = to the session's user ID, you can simply return the user_id from this function. - Post email verification, the session claim will be updated to signify that the email is verified, and then you can start the sign up flow in which you can generate a username and ask the user for their optional password and then call the sign up API with that. You also want to override that API to mark the username as verified in the email verification recipe. ---------- The advantage of this flow is that you don't actually create a user in supertokens until after email verification - so you don't need to make any cronjob to delete user or anything. If a user starts the flow and abandons it, the email verification token + session will eventually get removed anyway.
But either flow is fine.. pick whichever you find easier. Since there is no example app for the second one, it may be quicker to just go with flow (1). However, flow (2) is cleaner.
a
Where is the session stored? (memcache, postgres, redis)?
r
the db connected to supertokens.
which is postgres / mysql depending on which db you have
for our managed service, it's postgres
a
and those rows are probably deleted after refresh_token_validity expires?
r
yes
a
OK - this is a lot of helpful information. I'm going to sit down and think about this. I'm probably going to go with flow #1. Thank you @rp_st !!!
r
Feel free to ask more questions!
a
Do I need to call 
/{apiBasePath}/user/email/verify/token
to send a verification email? Or is there a way for this to be sent when 
/{apiBasePath}/signup
is called?
Also - I'd like a code to be sent not a link for verification 🤔 . Looking through the docs. :). Nothing yet.
Okay, I think I'm going to change it. I'm going to do the verification myself (I've already set it up with mailchimp) :). But now I want to create the user + create the session (correct auth headers) from my same endpoint so the client doesn't need another round trip. Can I do this via python via the SDK instead of through HTTP?
r
Yea. You can use the sign_up function from emailpassword recipe and then call the create_new_session function from the session recipe after. That should do it.
Out of curiosity, why did you not use supertokens for email verification? You can hook up mailchimp with us as well by overriding the send_email function. The advantage is that we would take care of managing the email verification token for you and making sure that it’s securely generated and consumed.
4 Views
PreviousNext
Powered by