Ok, sorry if this is a naive question! I want to restrict the list of users that can register for my app, invite-only style. Is there a best practice way to implement this? Could I do this as a post-authentication hook or does this need to be in an override?

Hey @User which recipe are you using?

ThirdPartyEmailPassword

Alright! So you will have to do the following: - Disable the

emailPasswordSignUpPOST

API function (API for signing up with email and password): https://supertokens.com/docs/thirdpartyemailpassword/advanced-customizations/apis-override/disabling - Override the

thirdPartySignInUp

recipe function (see https://supertokens.com/docs/thirdpartyemailpassword/advanced-customizations/backend-functions-override/usage) -> the input to the function has the email ID of the user who is trying to sign up. Use that to check if it's already a user by calling

ThirdPartyEmailPassword.getUsersByEmail(..)

-> If this returns an array of size 0, then throw an error which will disallow sign up, else call the orginal implementation (signing in the user).

Ah, sorry for delay. Thank you so much! I'll let you know how it goes🙂

So you would need to check if it's a user you want to allow to login via thirdparty login based on some list you store somewhere (you can store their email ID in that list), OR if

ThirdPartyEmailPassword.getUsersByEmail(..)

returns a non empty list back (indicating this user already exists in your system).

Gotcha! Makes sense

> So in this case, anyone can sign up but only validate on sign in No. Only people you allow can sign in (which I think is what you want?)

Right. But just in terms of ux, I wouldn't want someone to be allowed to register but not actually sign in

That's why you check

ThirdPartyEmailPassword.getUsersByEmail(..)

too. If this returns a non empty array, it means they are already registered. So you should then call the original impl allowing them to sign in. So people using social login would not be able to login if and only if

ThirdPartyEmailPassword.getUsersByEmail(..)

returns an empty array (for their email), AND, you have not whitelisted their email in some list stored in your db.

Oh ok, I follow. I think the third-party part of the flow was throwing me off

right. Feel free to ask more questions!

I appreciate it!

@Les see this

Thanks rp, i think i was on the right path. 2 questions, Is my assumption correct it's the same for the Google Recipe and why should I disable signupPost? (just curious)

google auth is in the thirdparty or the thirdpartyemailpassword recipe. You can pick whichever you want. You should disable signupPost cause thats the API that the frontend calls and if you dont disable it, someone can still technicaly call that API manually and create users.

Hey @rp I've finally come back to this project and settled on passwordless instead of thirdparty for the time being. I'm trying to implement an override for `consumeCode`/`consumeCodePOST` but the

input

doesn't have the email the user tried to sign in/up with so I can't do a conditional check before supertokens creates the user + session, which is undesirable (I think). Is there a way to extract the user email from the

input

without using

consumeCode

first?

Hey! Instead of overriding that api, override the createCodePOST API. That has the input email directly in it.

ooooh, 🤦‍♂️ that makes way more sense. thank you