Post sign up callbacks
1. On the frontend
What type of UI are you using?
This method allows you to fire events immediately after a successful sign up. For example to send analytics events post sign up.
import SuperTokens from "supertokens-auth-react";
import EmailPassword from "supertokens-auth-react/recipe/emailpassword";
import Session from "supertokens-auth-react/recipe/session";
SuperTokens.init({
appInfo: {
apiDomain: "...",
appName: "...",
websiteDomain: "..."
},
recipeList: [
EmailPassword.init({
onHandleEvent: async (context) => {
if (context.action === "SUCCESS") {
if (context.isNewRecipeUser && context.user.loginMethods.length === 1) {
// TODO: Sign up
} else {
// TODO: Sign in
}
}
}
}),
Session.init()
]
});
Please refer to this page to learn more about the onHandleEvent hook.
2. On the backend
Sign up override
For this, you'll have to override the signUp function in the init function call.
import SuperTokens from "supertokens-node";
import EmailPassword from "supertokens-node/recipe/emailpassword";
import Session from "supertokens-node/recipe/session";
// backend
SuperTokens.init({
appInfo: {
apiDomain: "...",
appName: "...",
websiteDomain: "..."
},
supertokens: {
connectionURI: "...",
},
recipeList: [
EmailPassword.init({
override: {
functions: (originalImplementation) => {
return {
...originalImplementation,
signUp: async function (input) {
// First we call the original implementation of signUp.
let response = await originalImplementation.signUp(input);
// Post sign up response, we check if it was successful
if (response.status === "OK" && response.user.loginMethods.length === 1 && input.session === undefined) {
/**
*
* response.user contains the following info:
* - emails
* - id
* - timeJoined
* - tenantIds
* - phone numbers
* - third party login info
* - all the login methods associated with this user.
* - information about if the user's email is verified or not.
*
*/
// TODO: post sign up logic
}
return response;
}
}
}
}
}),
Session.init({ /* ... */ })
]
});
Using the code above, you can (for example):
- Add the user's ID and their info to your own database (in addition to it being stored in SuperTokens).
- Send analytics events about a sign up.
- Send a welcome email to the user.
- You can associate a role to the user.
Accessing custom form fields during email password sign up
During email password sign up, if you would like to access the custom form fields that you may have added, you can do so by overriding the signUpPOST API:
import SuperTokens from "supertokens-node";
import EmailPassword from "supertokens-node/recipe/emailpassword";
import Session from "supertokens-node/recipe/session";
// backend
SuperTokens.init({
appInfo: {
apiDomain: "...",
appName: "...",
websiteDomain: "..."
},
supertokens: {
connectionURI: "...",
},
recipeList: [
EmailPassword.init({
override: {
apis: (originalImplementation) => {
return {
...originalImplementation,
signUpPOST: async function (input) {
// First we call the original implementation of signUpPOST.
let response = await originalImplementation.signUpPOST!(input);
// Post sign up response, we check if it was successful
if (response.status === "OK" && response.user.loginMethods.length === 1 && input.session === undefined) {
/**
*
* response.user contains the following info:
* - emails
* - id
* - timeJoined
* - tenantIds
* - phone numbers
* - third party login info
* - all the login methods associated with this user.
* - information about if the user's email is verified or not.
*
*/
// TODO: sign up successful
// here we fetch a custom form field for the user's name.
// Note that for this to be available, you need to define
// this custom form field.
let name = ""
for (let i = 0; i < input.formFields.length; i++) {
if (input.formFields[i].id == "name") {
name = input.formFields[i].value as string;
}
}
// Use name..
}
return response;
}
}
},
functions: (originalImplementation) => {
return {
...originalImplementation,
// TODO: from previous code snippets
}
}
}
}),
Session.init({ /* ... */ })
]
});
API override vs Functions override
For most purposes, you should be using Functions override. Functions override logic is called whenever the API is called from the frontend as well as if you call the sign up / sign in functions yourself manually via the SDK (like emailpassword.SignIn(...)).
For example, when the frontend calls the email password sign up API, the SDK invokes the API.SignUpPOST above. When you call the original implementation of this function, that function calls the Functions.SignUp function first, and if that's successful, it calls the Session recipe's createNewSession function.
Therefore, if you want to associate a role with a user, you would want to do that in the Functions.SignUp function since then those roles would get added to the session in the subsequent call to the Session.createNewSession function. If instead, you associate a role to the user in the API.SignUpPOST (after calling the original implementation), the role will not be automatically added to the session since the Session.createNewSession would have already been called before the original implementation returns.
The only time it makes sense to override the API functions is if you want to access an argument that's not available in the recipe function. For example, the custom form fields for email password sign up is an input to the API.SignUpPOST, but not to the Functions.SignUp, so if you want to access the form fields, you should override the API.SignUpPOST as shown above. You can also always add the formFields to the userContext object and read it later in the Functions.SignUp override, but then you would lose the typing of the form field array structure (which is not a runtime problem, but just a slightly bad developer experience).