11/28/2022, 3:59 PM
yes you can do both.
1) use the emailpassword login recipe and modify the email validators to accept any string. You can change the label on the frontend pre built UI to change "Email" to "Username" using the language translation feature.
2) We use the concepts of override (like in inheritance), using which you can modify the logic for any API exposed by supertokens. For example, see this on how to do post sign up stuff: https://supertokens.com/docs/emailpassword/common-customizations/handling-signup-success
11/28/2022, 4:06 PM
Ok cool so then if I'm overriding the emailPassword stuff for a username, but still want an optional email address for each user, I would just add another metadata field for the email?
11/28/2022, 4:09 PM
Yea.. but instead of storing the email in metadata, you should store in your own db cause then you can enforce uniqueness of emails.
Also, you may want to override the reset password related functions to get the email from your db (if it exists), instead of using our default impl, which will get the username, which ofc won't work.
11/28/2022, 4:12 PM
Yes I am also making a MongoDB for some user specific data. So I can just use supertokens for auth and push everything else into the mongo user entry
11/28/2022, 4:15 PM
yea. Pretty much
11/29/2022, 3:04 PM
One last question. Each user is going to get generated a key that needs to be encrypted at rest like a password. Would supertokens or my mongodb be the better choice for where to safely store this?
11/29/2022, 3:15 PM
If you want to always fetch the that key from the userId, then you can use the supertokens metadata recipe to store it against the user.
If you want to fetch that key based on some other criteria other than the user Id, then you should store it in your own db.