ReactJS SDK that provides login functionality with SuperTokens.
ReactJS SDK that provides login functionality with SuperTokens.
Learn more at https://supertokens.io
To see documentation, please click here.
Please refer to the CONTRIBUTING.md file in this repo.
For any queries, or support requests, please email us at team@supertokens.io, or join our Discord server.
Created with :heart: by the folks at SuperTokens.io.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning
supertokens
Webauthn recipe and prebuilt UI with passkey, webauthn-platform, and webauthn-resident support--palette-caution: Used for showing cautionary messages--palette-errorDark: Used for showing error messages with a darker shade--palette-buttonGreyedOut: Used in some disabled buttonswebauthn as a possible factoridAuthPage was using full-page redirects to navigate to the password reset page if both emailpassword and passwordless were enabled.OAuth2Provider recipeAuthPageHeader to show the client information in OAuth2 flowsAuthPage to help with common errorsgetRedirectionURL functions now also get a new tenantIdFromQueryParams propgetTenantId implementationtenantId query param during internal redirections between pages handled by the SDK.shouldTryLinkingToSessionUser flag to sign in/up related function inputs:false (or leave as undefined) during first factor sign-instrue for secondary factors.EmailPassword:signIn, signUp: both override and callable functionsThirdParty:getAuthorisationURLWithQueryParamsAndSetState: both override and callable functionredirectToThirdPartyLogin: callable function takes this flag as an optional input (it defaults to false on the backend)Passwordless:consumeCode, resendCode, createCode, setLoginAttemptInfo, getLoginAttemptInfocreateCode and setLoginAttemptInfo take this flag as an optional input (it defaults to false on the backend)getTenantId to default to the tenantId query parameter (if present) then falling back to the public tenant instead of always defaulting to the public tenantconsumeCode function in the Passwordless RecipeBefore:
EmailPassword.init({
async getRedirectionURL(context) {
if (context.action === "RESET_PASSWORD") {
return `/reset-password`;
}
return "";
},
});After:
EmailPassword.init({
async getRedirectionURL(context) {
return `/reset-password?tenantId=${context.tenantIdFromQueryParams}`;
},
});You can re-enable linking by overriding the consumeCode function in the passwordless recipe and setting shouldTryLinkingToSessionUser to true.
Passwordless.init({
override: {
functions: (original) => {
return {
...original,
consumeCode: async (input) => {
// Please note that this is means that the session is required and will cause an error if it is not present
return original.consumeCode({ ...input, shouldTryLinkingWithSessionUser: true });
},
};
},
},
});Redesigned the pre-built UI with a modern monochrome aesthetic, creating a cleaner and more unified visual experience. Please double check any custom styles you added still looks good with the new UI.
--palette-textTitle changed from rgb(34, 34, 34) to rgb(0, 0, 0)--palette-textLabel changed from rgb(34, 34, 34) to rgb(0, 0, 0)--palette-textInput changed from rgb(34, 34, 34) to rgb(0, 0, 0)--palette-textPrimary changed from rgb(101, 101, 101) to rgb(128, 128, 128)--palette-textLink changed from rgb(0, 118, 255) to rgb(0, 122, 255)--palette-textGray changed from rgb(128, 128, 128) to rgb(54, 54, 54)EMAIL_VERIFICATION_SEND_TITLEPWLESS_LINK_SENT_RESEND_DESC_END_EMAILredirectToFactor to accept an object instead of multiple arguments.redirectToFactorChooser to accept an object instead of multiple arguments.stepUp query param is not set to true.redirectToFactorChooser now accepts a stepUp option to set the stepUp query param.redirectToFactor now accepts a stepUp option to set the stepUp query param.Session recipe was not allowed in the pre-built UI list (it's still a no-op, but it shouldn't be a type issue)maxAgeInSeconds value (previously 300 seconds) in EmailVerification Claim. If the claim value is true and maxAgeInSeconds is not provided, it will not be refreshed.ThirdPartyEmailPassword and ThirdPartyPasswordless recipes.EmailPassword recipe:
SignInUp, SignInAndUpThemeEmailPasswordSignIn, EmailPasswordSignInFooter, EmailPasswordSignInHeader, EmailPasswordSignUp, EmailPasswordSignUpFooter, EmailPasswordSignUpHeaderuseShadowDom, defaultToSignUp, privacyPolicyLink, termsOfServiceLink from the config to the root configuration passed to SuperTokens.init.Passwordless recipe:
SignInUpPasswordlessSignInUpHeader_Override, PasswordlessSignInUpFooter_OverrideguessInternationPhoneNumberFromInputPhoneNumber configurable callback, since now the user sets if they are entering email or a phone number explicitlyuseShadowDom, privacyPolicyLink, termsOfServiceLink from the config to the root configuration passed to SuperTokens.init.EMAIL_OR_PHONEdefaultToEmail configuration option, which decides if the contact info input form starts in the email or phone state if the contactMethod is set to EMAIL_OR_PHONEThirdParty recipe:
SignInAndUpThirdPartySignInAndUpHeader, ThirdPartySignUpFooteruseShadowDom, privacyPolicyLink, termsOfServiceLink from the config to the root configuration passed to SuperTokens.init.Removed SESSION_ALREADY_EXISTS event from auth recipes and moved it into the Session recipe
data-supertokens props of several elementsEMAIL_PASSWORD_SIGN_IN_FORGOT_PW_LINK instead of EMAIL_PASSWORD_SIGN_IN_FOOTER_FORGOT_PW_LINKAUTH_PAGE_HEADER_TITLE_SIGN_IN_AND_UP instead of PWLESS_SIGN_IN_UP_HEADER_TITLE and THIRD_PARTY_SIGN_IN_AND_UP_HEADER_TITLEAUTH_PAGE_HEADER_TITLE_SIGN_IN instead of EMAIL_PASSWORD_SIGN_IN_HEADER_TITLEAUTH_PAGE_HEADER_SUBTITLE_SIGN_UP_START instead of EMAIL_PASSWORD_SIGN_IN_HEADER_SUBTITLE_STARTAUTH_PAGE_HEADER_SUBTITLE_SIGN_UP_SIGN_IN_LINK instead of EMAIL_PASSWORD_SIGN_IN_HEADER_SUBTITLE_SIGN_UP_LINKAUTH_PAGE_HEADER_SUBTITLE_SIGN_UP_END instead of EMAIL_PASSWORD_SIGN_IN_HEADER_SUBTITLE_ENDAUTH_PAGE_HEADER_TITLE_SIGN_UP instead of EMAIL_PASSWORD_SIGN_UP_HEADER_TITLEAUTH_PAGE_HEADER_SUBTITLE_SIGN_IN_START instead of EMAIL_PASSWORD_SIGN_UP_HEADER_SUBTITLE_STARTAUTH_PAGE_HEADER_SUBTITLE_SIGN_IN_SIGN_UP_LINK instead of EMAIL_PASSWORD_SIGN_UP_HEADER_SUBTITLE_SIGN_IN_LINKAUTH_PAGE_HEADER_SUBTITLE_SIGN_IN_END instead of EMAIL_PASSWORD_SIGN_UP_HEADER_SUBTITLE_ENDAUTH_PAGE_FOOTER_START instead of EMAIL_PASSWORD_SIGN_UP_FOOTER_START, PWLESS_SIGN_IN_UP_FOOTER_START and THIRD_PARTY_SIGN_IN_UP_FOOTER_STARTAUTH_PAGE_FOOTER_TOS instead of: EMAIL_PASSWORD_SIGN_UP_FOOTER_TOS, PWLESS_SIGN_IN_UP_FOOTER_TOS and THIRD_PARTY_SIGN_IN_UP_FOOTER_TOSAUTH_PAGE_FOOTER_AND instead of EMAIL_PASSWORD_SIGN_UP_FOOTER_AND, PWLESS_SIGN_IN_UP_FOOTER_AND and THIRD_PARTY_SIGN_IN_UP_FOOTER_ANDAUTH_PAGE_FOOTER_PP instead of EMAIL_PASSWORD_SIGN_UP_FOOTER_PP, PWLESS_SIGN_IN_UP_FOOTER_PP and THIRD_PARTY_SIGN_IN_UP_FOOTER_PPAUTH_PAGE_FOOTER_END instead of EMAIL_PASSWORD_SIGN_UP_FOOTER_END, PWLESS_SIGN_IN_UP_FOOTER_END and THIRD_PARTY_SIGN_IN_UP_FOOTER_ENDAuthPageComponentList, AuthPageHeader, AuthPageFooter.AuthRecipeComponentsOverrideContextProviderPasswordless: PasswordlessContinueWithPasswordless_OverrideAuthPage and AuthPageThemeEmailPassword: SignInTheme, SignUpThemestyle prop to the root level configIf you were using ThirdPartyEmailPassword, you should now init ThirdParty and EmailPassword recipes separately. The config for the individual recipes are mostly the same, except the syntax may be different. Check our recipe guides for ThirdParty and EmailPassword for more information.
If you were using ThirdPartyPasswordless, you should now init ThirdParty and Passwordless recipes separately. The config for the individual recipes are mostly the same, except the syntax may be different. Check our recipe guides for ThirdParty and Passwordless for more information.
Several configuration options (useShadowDom, defaultToSignUp, privacyPolicyLink, termsOfServiceLink) were moved to the root configuration (the one passed directly to SuperTokens.init) out of recipe specific configs. The function of these props remain identical, the only necessary migration is moving them:
Before:
SuperTokens.init({
appInfo: {
// appInfo
},
recipeList: [
EmailPassword.init({
useShadowDom: false,
signInAndUpFeature: {
defaultToSignUp: true,
signUpForm: {
privacyPolicyLink: "http://example.com",
termsOfServiceLink: "http://example.com",
},
},
}),
Session.init(),
],
});After:
SuperTokens.init({
appInfo: {
// appInfo
},
useShadowDom: false,
defaultToSignUp: true,
privacyPolicyLink: "http://example.com",
termsOfServiceLink: "http://example.com",
recipeList: [EmailPassword.init(), Session.init()],
});The auth page related embeddable components (SignInAndUp, SignInUp) and the related theme components were removed. We instead recommend you to use the new AuthPage component with the appropriate pre-built UI objects and factorsIds set. For more information check the following guide
Before:
import { SignInAndUp } from "supertokens-auth-react/recipe/thirdpartyemailpassword/prebuiltui";
const Component = () => {
const navigate = useNavigate();
return <SignInAndUp navigate={navigate} />;
};After:
import { PasswordlessPreBuiltUI } from "supertokens-auth-react/recipe/passwordless/prebuiltui";
import { AuthPage } from "supertokens-auth-react/ui";
const Component = () => {
const navigate = useNavigate();
return <AuthPage preBuiltUIList={[PasswordlessPreBuiltUI]} factors={["otp-phone"]} navigate={navigate} />;
};Some parts of our default styles have been changed, including some changes to the data-supertokens props added to elements. Since customizations can take many forms we cannot give you exact guidance on how/what needs to change. In almost all cases, no updates should be required, but please check that your custom styles still work as you expect.
inputComponents (in sign in/up form fields) now get reference-stable callbacks.The shouldDoInterceptionBasedOnUrl function now returns true:
onFailureRedirection is no longer allowed to return relative paths.onFailureRedirection returns the current URL or path when:websiteBasePath, usually /auth) when a session already exists,clearOnSubmit now only clears the field value if the request returned an error. This is because the form navigates on success, making clearing the field unnecessary (which can lead to confusing UX if the navigation takes too long).SessionAuth contents popped in before navigating away if a claim validator failed:onFailureRedirection returned the current URL.onFailureRedirection returned something different than the current URL.name property optional in custom provider configs for usage with usesDynamicLoginMethods, where the tenant configuration is expected to set the name dynamically.usesDynamicLoginMethods is set to false or if the tenant configuration doesn't include a provider list.With this release, we are introducing MultiFactorAuth and TOTP, this will let you:
Check our guide for more information.
SUCCESS redirections are now handled by the getRedirectionURL callback passed to the SuperTokens.init config, instead of the recipe level callbacksisNewPrimaryUser is renamed to createdNewUserresetPasswordHeaderTitle -> headerTitle withBackButton)headerSubtitle is styled in components: EmailPasswordResetPasswordEmail, EmailPasswordSubmitNewPassword, EmailPasswordSignInHeader, EmailPasswordSignUpHeaderErrorBoundary wrapping all our feature components to make sure all errors are properly catchable by the appsupertokens-web-js (which you may also be using), we added firstFactors into the return type of getLoginMethods and removed the enabled flags of different login methods.validatorId in claim validation errors to id to match the backend SDKsBefore:
import SuperTokens, { SuperTokensWrapper, getSuperTokensRoutesForReactRouterDom } from "supertokens-auth-react";
import Passwordless from "supertokens-auth-react/recipe/passwordless";
SuperTokens.init({
appInfo: {
// appInfo
},
recipeList: [
Passwordless.init({
contactMethod: "EMAIL_OR_PHONE",
async getRedirectionURL(context) {
if (context.action === "SUCCESS") {
if (context.isNewRecipeUser) {
// new primary user
} else {
// only a recipe user was created
}
}
return undefined;
},
}),
Session.init(),
],
});After:
import SuperTokens, { SuperTokensWrapper, getSuperTokensRoutesForReactRouterDom } from "supertokens-auth-react";
import Passwordless from "supertokens-auth-react/recipe/passwordless";
SuperTokens.init({
appInfo: {
// appInfo
},
async getRedirectionURL(context, userContext) {
if (context.action === "SUCCESS" && context.newSessionCreated) {
if (context.createdNewUser && context.recipeId === "passwordless") {
// custom logic
}
}
// Returning undefined means we use the default redirection
return undefined;
},
recipeList: [
Passwordless.init({
contactMethod: "EMAIL_OR_PHONE",
}),
Session.init(),
],
});There are 2 types of style changes in this release:
Refactored/renamed some styling options. If you didn't add custom styles for the following classes there is no action needed
resetPasswordHeaderTitle: should now be styled using withBackButtonheaderSubtitle: now directly includes the text instead of a div, your styles may require an update to match this changeSome default styling has changed related to how fonts/font-weights are applied. This may interact with your own font/sizing settings, if you didn't add font, font-size/weight and size changes to your custom styles, no action should be needed.
Both of the above changes could have subtle interactions with custom styles, so we recommend a quick manual (visual) test to make sure everything still looks right.
If you used to use the enabled flags in getLoginMethods:
Before:
async function checkLoginMethods() {
const loginMethods = await Multitenancy.getLoginMethods();
if (loginMethods.thirdParty.enabled) {
// custom logic
}
if (loginMethods.emailPassword.enabled) {
// custom logic
}
if (loginMethods.passwordless.enabled) {
// custom logic
}
}After:
async function checkLoginMethods() {
const loginMethods = await Multitenancy.getLoginMethods();
if (loginMethods.firstFactors.includes("thirdparty")) {
// custom logic
}
if (loginMethods.firstFactors.includes("emailpassword")) {
// custom logic
}
if (
loginMethods.firstFactors.includes("otp-email") ||
loginMethods.firstFactors.includes("otp-phone") ||
loginMethods.firstFactors.includes("link-email") ||
loginMethods.firstFactors.includes("link-phone")
) {
// custom logic
}
}Before:
import SuperTokens, { SuperTokensWrapper, getSuperTokensRoutesForReactRouterDom } from "supertokens-auth-react";
import Passwordless from "supertokens-auth-react/recipe/passwordless";
SuperTokens.init({
appInfo: {
// appInfo
},
recipeList: [
Passwordless.init({
contactMethod: "EMAIL_OR_PHONE",
onHandleEvent(context) {
if (context.action === "SUCCESS") {
let user = context.user;
if (context.isNewRecipeUser && context.user.loginMethods.length === 1) {
// sign up success
} else {
// sign in success
}
}
},
}),
Session.init(),
],
});After:
import SuperTokens, { SuperTokensWrapper, getSuperTokensRoutesForReactRouterDom } from "supertokens-auth-react";
import Passwordless from "supertokens-auth-react/recipe/passwordless";
SuperTokens.init({
appInfo: {
// appInfo
},
recipeList: [
Passwordless.init({
contactMethod: "EMAIL_OR_PHONE",
onHandleEvent(context) {
if (context.action === "SUCCESS" && context.createdNewSession) {
let user = context.user;
let rid = context.rid;
if (context.isNewRecipeUser && context.user.loginMethods.length === 1) {
// sign up success
} else {
// sign in success
}
}
},
}),
Session.init(),
],
});If you used to use the validatorId prop of validationErrors, you should now use id instead.
Before:
async function checkValidators() {
const validationErrors = await Session.validateClaims();
for (const error of validationErrors) {
console.log(error.validatorId, error.reason);
}
}After:
async function checkValidators() {
const validationErrors = await Session.validateClaims();
for (const error of validationErrors) {
console.log(error.id, error.reason);
}
}MultiFactorAuth and TOTP recipes. To start using them you'll need compatible versions:mfaFeature to recipe configdisableDefaultUI: can be used to disable paths: ${websiteBasePath}/mfa/otp-phone, ${websiteBasePath}/mfa/otp-emailstyle: is applied on top of normal sign in/up styles on the MFA pathsMfaOtpPhone (by default handling path ${websiteBasePath}/mfa/otp-phone)MfaOtpEmail (by default handling path ${websiteBasePath}/mfa/otp-email)PasswordlessMFAHeader_OverridePasswordlessMFAFooter_OverridePasswordlessMFAOTPHeader_OverridePasswordlessMFAOTPFooter_OverridePasswordlessEmailForm_OverridePasswordlessPhoneForm_OverridePasswordlessEmailOrPhoneForm_OverrideuseShadowDom prop to the AccessDeniedScreenerror prop to the AccessDeniedScreen that can be used to describe the reason access is denied.footer prop to EmailOrPhoneForm, EmailForm and PhoneForm which is used to override the default sign in/up footers in case the component is for MFAfirstFactors config value into account (defined in the MultiFactorAuth recipe or in the tenant information)MultiFactorAuth recipe or in the tenant information) when selecting the available contact methods.rid and createdNewSession to events with action: "SUCCESS"redirectToAuth with the redirectBack option, url fragments(hash) were stripped when redirecting back to the previous page after authentication. This issue has been fixed, and url fragments are preserved along with the query params. For users who employed the workaround of overriding the windowHandler.location.getSearch function to include fragments, it is essential to remove that override before upgrading to this version.builder non optional.DateProvider implementation relies on localStorage. If your environment lacks support for localStorage, you must provide custom implementations for either the DateProvider or localStorage.DateProvider from supertokens-web-js, that both built-in and custom validators can use instead of Date.now to get an estimate of the server clock.dateProvider prop to the configuration that can be used to customize the built-in DateProvider.calculateClockSkewInMillis as an overrideable function to the Session recipe that estimates the time difference between the backend and the client.redirectToAuth with the redirectBack option, query parameters were stripped when redirecting back to the previous page after authentication. This issue has been fixed, and now query parameters are preserved as intended.getRedirectionURL now supports returning null to prevent automatic redirection, useful for customizing the behavior after successful sign-in or sign-up. Typically, this is used if you want to embed the sign in / up component in a popup and want to just dismiss the popup post login.Here's an example of how to use this:
EmailPassword.init({
getRedirectionURL: async (context, userContext) => {
if (context.action === "SUCCESS") {
return null;
}
// Returning undefined falls back to the default redirection strategy
return undefined;
},
});getRedirectionURL now receives userContext as the second argument.
isNewPrimaryUser boolean property has been added to GetRedirectionURLContext. It can be used to check if a new primary user was created particularly in scenarios involving account linking.
UserContext type has been changed to Record<string, unknown> from any.
The PreBuiltUI components now accept a navigate prop, internally utilized by SuperTokens for redirection. This becomes handy when manually rendering the component and desiring client-side navigation instead of a full-page refresh for any redirection. Here's an example using react-router-dom@v6:
import { SignInUp } from "supertokens-auth-react/recipe/passwordless/prebuiltui";
import { useNavigate } from "react-router-dom";
function CustomSignInUp() {
const navigate = useNavigate();
return <SignInUp navigate={navigate} />;
}user property has been removed from GetRedirectionURLContext.To get the user object from backend, you can follow hte instructions here.
The CloseTabScreen component, previously featured in the passwordless recipe visible when a user signs in from another tab using a magic link, has been removed. Users will continue to see the 'Enter OTP' screen until they refresh. If you were overriding this component using PasswordlessCloseTabScreen_Override, you no longer need to do so.
If your workflow involves custom validation, such as Phone Number verification, after signing in, ensure your code aligns with the updated examples found in with-phone-password or with-thirdpartyemailpassword-passwordless.
Changes:
props.featureState.successInAnotherTab to false to avoid displaying the CloseTabScreen component has been eliminated.SignInAndUpHeader_Override in this case (overrideable as ThirdPartySignInAndUpHeader). Overriding ThirdPartyEmailPasswordHeader_Override should still cover all cases.ThirdPartyEmailPasswordHeader_Override you can use to check if email password is enabled.inputComponent props to make them non optional. This is in the context of customizing the sign up form to add custom react components.inputComponent types.onChange prop in inputComponent simpler by removing the need for an id attribute.nonOptionalErrorMsg prop.Following is an example of how to use above features.
EmailPassword.init({
signInAndUpFeature: {
signUpForm: {
formFields: [
{
id: "select-dropdown",
label: "Select Option",
getDefaultValue: () => "option 2",
nonOptionalErrorMsg: "Select dropdown is required",
inputComponent: ({ value, name, onChange }) => (
<select
value={value}
name={name}
onChange={(e) => onChange(e.target.value)}
placeholder="Select Option">
<option value="" disabled hidden>
Select an option
</option>
<option value="option 1">Option 1</option>
<option value="option 2">Option 2</option>
<option value="option 3">Option 3</option>
</select>
),
},
],
},
},
});
ThirdPartyEmailPassword.init({
signInAndUpFeature: {
signUpForm: {
formFields: [
{
id: "terms",
label: "",
optional: false,
getDefaultValue: () => "true",
nonOptionalErrorMsg: "You must accept the terms and conditions",
inputComponent: ({ name, onChange, value }) => (
<div
style={{
display: "flex",
alignItems: "center",
justifyContent: "left",
}}>
<input
value={value}
checked={value === "true"}
name={name}
type="checkbox"
onChange={(e) => onChange(e.target.checked.toString())}></input>
<span style={{ marginLeft: 5 }}>I agree to the terms and conditions</span>
</div>
),
},
],
},
},
});autocomplete in passwordless forms for email, phone and OTPtwitter as id by default in twitter provider.Added new social provider twitter
Introduced a new option logo for thirdparty custom providers to set a custom logo, just like the name property.
Following is an example of how to use this new logo property.
ThirdPartyPasswordless.init({
signInUpFeature: {
providers: [
ThirdPartyPasswordless.Google.init(),
ThirdPartyPasswordless.Apple.init(),
{
id: "discord",
name: "Discord",
logo: <svg
xmlns="http://www.w3.org/2000/svg"
height="1em"
viewBox="0 0 640 512"
>
<path d="M524.531,69.836a1.5,1.5,0,0,0-.764-.7A485.065,485.065,0,0,0,404.081,32.03a1.816,1.816,0,0,0-1.923.91,337.461,337.461,0,0,0-14.9,30.6,447.848,447.848,0,0,0-134.426,0,309.541,309.541,0,0,0-15.135-30.6,1.89,1.89,0,0,0-1.924-.91A483.689,483.689,0,0,0,116.085,69.137a1.712,1.712,0,0,0-.788.676C39.068,183.651,18.186,294.69,28.43,404.354a2.016,2.016,0,0,0,.765,1.375A487.666,487.666,0,0,0,176.02,479.918a1.9,1.9,0,0,0,2.063-.676A348.2,348.2,0,0,0,208.12,430.4a1.86,1.86,0,0,0-1.019-2.588,321.173,321.173,0,0,1-45.868-21.853,1.885,1.885,0,0,1-.185-3.126c3.082-2.309,6.166-4.711,9.109-7.137a1.819,1.819,0,0,1,1.9-.256c96.229,43.917,200.41,43.917,295.5,0a1.812,1.812,0,0,1,1.924.233c2.944,2.426,6.027,4.851,9.132,7.16a1.884,1.884,0,0,1-.162,3.126,301.407,301.407,0,0,1-45.89,21.83,1.875,1.875,0,0,0-1,2.611,391.055,391.055,0,0,0,30.014,48.815,1.864,1.864,0,0,0,2.063.7A486.048,486.048,0,0,0,610.7,405.729a1.882,1.882,0,0,0,.765-1.352C623.729,277.594,590.933,167.465,524.531,69.836ZM222.491,337.58c-28.972,0-52.844-26.587-52.844-59.239S193.056,219.1,222.491,219.1c29.665,0,53.306,26.82,52.843,59.239C275.334,310.993,251.924,337.58,222.491,337.58Zm195.38,0c-28.971,0-52.843-26.587-52.843-59.239S388.437,219.1,417.871,219.1c29.667,0,53.307,26.82,52.844,59.239C470.715,310.993,447.538,337.58,417.871,337.58Z" />
</svg>,
...With this release, we are introducing AccountLinking, this will let you:
Check our guide for more information.
To use this you'll need compatible versions:
createdNewUser has been renamed to createdNewRecipeUsercreateCode, consumeCode, createPasswordlessCode and consumePasswordlessCode can now return status: SIGN_IN_UP_NOT_ALLOWEDsignInAndUp and thirdPartySignInAndUp can now return new status: SIGN_IN_UP_NOT_ALLOWEDsendPasswordResetEmail can now return status: "PASSWORD_RESET_NOT_ALLOWED"signIn and emailPasswordSignIn can now return SIGN_IN_NOT_ALLOWEDsignUp and emailPasswordSignUp can now return SIGN_UP_NOT_ALLOWEDgetRedirectionURL gets an optional user prop (it's always defined if createdNewRecipeUser is set to true)We've added a generic User type instead of the old recipe specific ones. The mapping of old props to new in case you are not using account-linking:
user.id stays user.iduser.email becomes user.emails[0]user.phoneNumber becomes user.phoneNumbers[0]user.thirdParty becomes user.thirdParty[0]user.timeJoined is still user.timeJoineduser.tenantIds is still user.tenantIds // Here res refers to the result the function/api functions mentioned above.
const isNewUser = res.createdNewRecipeUser && res.user.loginMethods.length === 1; const isNewUser = res.user.loginMethods.length === 1;getRedirectionURLEmailPassword.init({ // This looks the same for other recipes
// Other config options.
async getRedirectionURL(context) {
if (context.action === "SUCCESS") {
if (context.isNewRecipeUser && context.user.loginMethods.length === 1) {
// new primary user
} else {
// only a recipe user was created
}
}
return undefined;
}
})onHandleEvent:EmailPassword.init({ // This looks the same for other recipes
// Other config options.
onHandleEvent(context: EmailPasswordOnHandleEventContext) {
if (context.action === "SUCCESS") {
if (context.isNewRecipeUser && context.user.loginMethods.length === 1) {
// new primary user
} else {
// only a recipe user was created
}
}
},
})getDynamicLoginMethods until the first feature/routing component rendersusesDynamicLoginMethods is true and getDynamicLoginMethods takes longer than 200msgetSuperTokensRoutesForReactRouterDom to support embedded routesgetClaimValueclientType config in the input for SuperTokens.init function, that is used by thirdparty and multitenancy recipes.usesDynamicLoginMethods config in the input for SuperTokens.init function, which makes the SDK check the backend to see which recipes should be enabledgetTenantIdFromURL to multiple recipesIn ThirdParty recipe,
Changed signatures of the functions getAuthorisationURLWithQueryParamsAndSetState
import { getAuthorisationURLWithQueryParamsAndSetState } from 'supertokens-auth-react/recipe/thirdparty';
getAuthorisationURLWithQueryParamsAndSetState({
- providerId: "google",
+ thirdPartyId: "google",
- authorisationURL: "http://localhost/auth/callback/google",
+ frontendRedirectURI: "http://localhost/auth/callback/google",
});Removed functions - setStateAndOtherInfoToStorage, getAuthorisationURLFromBackend, generateStateToSendToOAuthProvider, verifyAndGetStateOrThrowError, getAuthCodeFromURL, getAuthErrorFromURL, getAuthStateFromURL
In ThirdPartyEmailpassword recipe,
Changed signatures of the functions getAuthorisationURLWithQueryParamsAndSetState
import { getAuthorisationURLWithQueryParamsAndSetState } from 'supertokens-auth-react/recipe/thirdpartyemailpassword';
getAuthorisationURLWithQueryParamsAndSetState({
- providerId: "google",
+ thirdPartyId: "google",
- authorisationURL: "http://localhost/auth/callback/google",
+ frontendRedirectURI: "http://localhost/auth/callback/google",
});Removed functions - setStateAndOtherInfoToStorage, getAuthorisationURLFromBackend, generateStateToSendToOAuthProvider, verifyAndGetStateOrThrowError, getAuthCodeFromURL, getAuthErrorFromURL, getAuthStateFromURL
In ThirdPartyPasswordless recipe,
Changed signatures of the functions getThirdPartyAuthorisationURLWithQueryParamsAndSetState
import { getAuthorisationURLWithQueryParamsAndSetState } from 'supertokens-auth-react/recipe/thirdpartypasswordless';
getAuthorisationURLWithQueryParamsAndSetState({
- providerId: "google",
+ thirdPartyId: "google",
- authorisationURL: "http://localhost/auth/callback/google",
+ frontendRedirectURI: "http://localhost/auth/callback/google",
});Removed functions - setThirdPartyStateAndOtherInfoToStorage, getAuthorisationURLFromBackend, generateThirdPartyStateToSendToOAuthProvider, verifyAndGetThirdPartyStateOrThrowError, getThirdPartyAuthCodeFromURL, getThirdPartyAuthErrorFromURL, getThirdPartyAuthStateFromURL
AccessDenied screenonFailureRedirection and showAccessDeniedOnFailure on claims and validators to make handling session claim validation failures easieraccessDeniedScreen prop to SessionAuth. The component passed as this prop is rendered if a claim validator (with showAccessDeniedOnFailure set to true) fails.AccessDeniedScreen to provide a useful default for the above accessDeniedScreen prop.textGray to the palette variables (used in the default access denied screen)SendVerifyEmail without a sessioninit call for non-react applications that use pre-built UI. See the issueThis version also initializes the web-js SDK. If you previously did that manually, you can remove/replace it with the auth-react init call.
From this version forward, the recommended way to use this SDK, even with Angular and Vue, is to initialize auth-react in the root component. Importing supertokens-auth-react will not pull React into your main bundle; only importing the prebuiltui modules will.
For more details, check out our quick setup guides for angular and vue.
import SuperTokens, { SuperTokensWrapper, getSuperTokensRoutesForReactRouterDom } from "supertokens-auth-react";
import Passwordless from "supertokens-auth-react/recipe/passwordless";
// .... other imports
SuperTokens.init({
appInfo: {
// appInfo
},
recipeList: [
Passwordless.init({
contactMethod: "EMAIL_OR_PHONE",
}),
Session.init(),
],
});
<SuperTokensWrapper>
<div className="App">
<Router>
<div className="fill">
<Routes>
{/* This shows the login UI on "/auth" route */}
{getSuperTokensRoutesForReactRouterDom(require("react-router-dom"))}
// ... other routes
</Routes>
</div>
<Footer />
</Router>
</div>
</SuperTokensWrapper>;Should become
import SuperTokens, { SuperTokensWrapper } from "supertokens-auth-react";
import { getSuperTokensRoutesForReactRouterDom } from "supertokens-auth-react/ui";
import Passwordless from "supertokens-auth-react/recipe/passwordless";
import { PasswordlessPreBuiltUI } from "supertokens-auth-react/recipe/passwordless/prebuiltui";
// .... other imports
SuperTokens.init({
appInfo: {
// appInfo
},
recipeList: [
Passwordless.init({
contactMethod: "EMAIL_OR_PHONE",
}),
Session.init(),
],
});
<SuperTokensWrapper>
<div className="App">
<Router>
<div className="fill">
<Routes>
{/* This shows the login UI on "/auth" route for Passwordless recipe */}
{getSuperTokensRoutesForReactRouterDom(require("react-router-dom"), [PasswordlessPreBuiltUI])}
// ... other routes
</Routes>
</div>
<Footer />
</Router>
</div>
</SuperTokensWrapper>;import React from "react";
import SuperTokens, { SuperTokensWrapper } from "supertokens-auth-react";
class App extends React.Component {
render() {
if (SuperTokens.canHandleRoute()) {
// This renders the login UI on the /auth route
return SuperTokens.getRoutingComponent();
}
return <SuperTokensWrapper>{/*Your app*/}</SuperTokensWrapper>;
}
}Should become
import { SuperTokensWrapper } from "supertokens-auth-react";
import { canHandleRoute, getRoutingComponent } from "supertokens-auth-react/ui";
import { PasswordlessPreBuiltUI } from "supertokens-auth-react/recipe/passwordless/prebuiltui";
class App extends React.Component {
render() {
if (canHandleRoute([PasswordlessPreBuiltUI])) {
// This renders the login UI on the /auth route
return getRoutingComponent([PasswordlessPreBuiltUI]);
}
return <SuperTokensWrapper>{/*Your app*/}</SuperTokensWrapper>;
}
}mocha-split-tests packagesupertokens-auth-react and supertokens-node for all example appssupertokens-web-js dependency that requires a backend SDK update to:sessionScope renamed to sessionTokenFrontendDomaincookieDomain renamed to sessionTokenBackendDomainAuthorization header instead of cookiestokenTransferMethod config optionsupertokens-web-js into devDependencies. If using npm version 6, you also need to install it with npm i --save supertokens-web-js. Later versions install it automatically.intl-tel-input)Before:
SuperTokens.init({
appInfo: {
apiDomain: "...",
appName: "...",
websiteDomain: "...",
},
recipeList: [
ThirdPartyEmailPassword.init({
style: {
container: {
fontFamily: "cursive",
},
},
}),
Session.init(),
],
});After:
SuperTokens.init({
appInfo: {
apiDomain: "...",
appName: "...",
websiteDomain: "...",
},
recipeList: [
ThirdPartyEmailPassword.init({
style: `
[data-supertokens~=container] {
font-family: cursive;
}
`,
}),
Session.init(),
],
});Before:
SuperTokens.init({
appInfo: {
apiDomain: "...",
appName: "...",
websiteDomain: "...",
},
recipeList: [
ThirdPartyEmailPassword.init({
palette: {
background: "#333",
inputBackground: "#292929",
textTitle: "white",
textLabel: "white",
textPrimary: "white",
error: "#ad2e2e",
textInput: "#a9a9a9",
textLink: "#a9a9a9",
},
}),
Session.init(),
],
});After:
SuperTokens.init({
appInfo: {
apiDomain: "...",
appName: "...",
websiteDomain: "...",
},
recipeList: [
ThirdPartyEmailPassword.init({
style: `
[data-supertokens~=container] {
--palette-background: 51, 51, 51;
--palette-inputBackground: 41, 41, 41;
--palette-inputBorder: 41, 41, 41;
--palette-textTitle: 255, 255, 255;
--palette-textLabel: 255, 255, 255;
--palette-textPrimary: 255, 255, 255;
--palette-error: 173, 46, 46;
--palette-textInput: 169, 169, 169;
--palette-textLink: 169, 169, 169;
}
`,
}),
Session.init(),
],
});SuperTokens.init({
recipeList: [
EmailPassword.init({
override: {
components: {
EmailPasswordSignIn_Override: ({ DefaultComponent, ...props }) => {
return (
<div>
<img src="octocat.jpg" />
<DefaultComponent {...props} />
</div>
);
},
},
},
}),
],
});Components override would move to override provider component's prop:
import EmailPassword, { EmailPasswordComponentsOverrideProvider } from "supertokens-auth-react/recipe/emailpassword";
SuperTokens.init({
recipeList: [EmailPassword.init()],
});
function App() {
return (
<SuperTokensWrapper>
<EmailPasswordComponentsOverrideProvider
components={{
EmailPasswordSignIn_Override: ({ DefaultComponent, ...props }) => {
return (
<div>
<img src="octocat.jpg" />
<DefaultComponent {...props} />
</div>
);
},
}}>
{/* The rest of JSX */}
</EmailPasswordComponentsOverrideProvider>
</SuperTokensWrapper>
);
}
export default App;doesSessionExistgetClaimValue function inside Session recipe - exposed because web-js exposes it too.validateClaims function in Session recipeaddAxiosInterceptors as deprecatedsuperTokensDoNotDoInterception to the hash of the request (works as a queryparam as well)consumeCoderedirectToAuth to props of the overrideable SendVerifyEmail component/auth/verify-email with an unknown/deleted user instead of showing an empty screensessionContext will now contain doesSessionExist: false instead of throwing an errorUserRoleClaim, PermissionClaim and EmailVerificationClaimoverrideGlobalClaimValidators and doRedirection to SessionAuth propsvalidateClaims, useClaimValue and getInvalidClaimsFromResponse to the Session recipeAPI_INVALID_CLAIM event to the Session recipeEmailVerification recipeEmailVerification recipeonSuccess prop on passwordless SignInUpPropsgetSuperTokensRoutesForReactRouterDom was used by a sub-component of SessionAuthEmailVerification.init like other recipes.OFF from possible EmailVerification recipe modes, default is updated to REQUIRED.EmailVerification recipe. You should configure them while initializing the EmailVerification recipe.SessionAuth instead.EmailVerification recipe directly.requireAuth now defaults to true in SessionAuth to match the behavior of the removed recipe specific wrappers.redirectToLogin from SessionAuth.redirectToAuth to SuperTokens out of auth recipes. You should now call SuperTokens.redirectToAuth() instead. In this function redirectBack defaults to true.SIGN_IN_AND_UP action from GetRedirectionURLContext of auth recipes. This should now be handled by passing a getRedirectionURL to SuperTokens.init that handles a context with the TO_AUTH action.SuperTokens.init({
// Normal init conf...
recipeList: [
EmailPassword.init({
getRedirectionURL: (context) => {
if (context.action === "SIGN_IN_AND_UP") {
// This handler should be moved to the SuperTokens.init level
return "/auth";
}
// All email verification related context should be now handled in the config of the EmailVerification recipe
},
onHandleEvent: () => {
// Handle email verification related events here in the onHandleEvent of the EmailVerification config
},
preAPIHook: (context) => {
// Move email verification related pre-API hooks into the preAPIHook of the EmailVerification config
},
postAPIHook: (context) => {
// Move email verification related post-API hooks into the postAPIHook of the EmailVerification config
}
emailVerificationFeature: {
mode: "REQUIRED",
// Any other props here should be moved into the config of the EmailVerification recipe
},
override: {
emailVerificationFeature: {
// These overrides should be moved into the config of the EmailVerification recipe
}
}
}),
]
})Should become:
SuperTokens.init({
// Normal init conf...
getRedirectionURL: (context) => {
if (context.action === "TO_AUTH") {
// Move handling the SIGN_IN_AND_UP action here
return "/auth";
}
},
recipeList: [
EmailVerification.init({
mode: "REQUIRED",
// Props from emailVerificationFeature of the EmailPassword.init config should be moved here.
override: {
// The overrides from emailVerificationFeature in the overrides of the EmailPassword config should be moved here
},
getRedirectionURL: (context) => {
// Move handling email verification related redirects here
},
onHandleEvent: () => {
// Handle email verification related events here
},
preAPIHook: (context) => {
// Move email verification related pre-API hooks here
},
postAPIHook: (context) => {
// Move email verification related post-API hooks here
},
}),
EmailPassword.init({}),
],
});function ProtectedHomeComponent() {
return (
<EmailPasswordAuth>
<Home />
</EmailPasswordAuth>
);
}Should become:
function ProtectedHomeComponent() {
return (
<SessionAuth>
<Home />
</SessionAuth>
);
}getRedirectURL configuration option to third-party providers. This can be used to set where the user is redirected back during the callback.inputBackground and textInput even while being pre-filledsupertokens-node version in example appsconsumePasswordlessCode in ThirdPartyPasswordless optional.redirectOnSessionExists prop that controls if it redirects away if a session exists on mount. Defaults to true.react-scripts in all examplesgetRedirectionURLsupertokens-web-js dependency versionuserContext would not get passed correctly for ThirdPartyPasswordless recipeSuperTokensWrapper intended to wrap around whole applications, providing a session contextloading to the session context. Please check if the session context is still loading before using other props. loading is always false inside components wrapped by AuthWrappers with requireAuth=trueFollowing is an example of how your components may have to change. If you had components like this:
// .... other imports
import SuperTokens, { getSuperTokensRoutesForReactRouterDom, SuperTokensWrapper } from "supertokens-auth-react";
import { useSessionContext } from "supertokens-auth-react/recipe/session";
import { ThirdPartyEmailPasswordAuth } from "supertokens-auth-react/recipe/thirdpartyemailpassword";
function Component() {
const sessionContext = useSessionContext();
return <div className="fill">{sessionContext.doesSessionExist ? "logged in" : "logged out"}</div>;
}
SuperTokens.init({
/* config... */
});
function App() {
return (
<div className="App">
<Router>
<div className="fill">
<Routes>
{getSuperTokensRoutesForReactRouterDom(require("react-router-dom"))}
<Route
path="/some-path"
element={
<ThirdPartyEmailPasswordAuth requireAuth={true}>
{/*
In this case, Component will always display logged in.
If doesSessionExist is false after the session is loaded, the user is redirected to the login screen
*/}
<Component />
</ThirdPartyEmailPasswordAuth>
}
/>
<Route
path="/"
element={
<ThirdPartyEmailPasswordAuth requireAuth={false}>
<Component />
</ThirdPartyEmailPasswordAuth>
}
/>
</Routes>
</div>
</Router>
</div>
);
}It'd look like this after the update:
// .... other imports
import SuperTokens, { getSuperTokensRoutesForReactRouterDom, SuperTokensWrapper } from "supertokens-auth-react";
import { useSessionContext } from "supertokens-auth-react/recipe/session";
import { ThirdPartyEmailPasswordAuth } from "supertokens-auth-react/recipe/thirdpartyemailpassword";
function Component() {
const sessionContext = useSessionContext();
if (sessionContext.loading === true) {
// You could display a loading screen here, but session context loading is very fast
// so returning null is better in most cases to avoid content popping in and out
return null;
}
return <div className="fill">{sessionContext.doesSessionExist ? "logged in" : "logged out"}</div>;
}
SuperTokens.init({
/* config is unchanged */
});
function App() {
return (
<div className="App">
<SuperTokensWrapper>
<Router>
<div className="fill">
<Routes>
{getSuperTokensRoutesForReactRouterDom(require("react-router-dom"))}
<Route
path="/some-path"
element={
<ThirdPartyEmailPasswordAuth requireAuth={true}>
{/*
In this case, Component will never hit the loading === true branch.
It will only be rendered if `loading === false && doesSessionExist === true`
If doesSessionExist is false after the session is loaded, the user is redirected to the login screen
*/}
<Component />
</ThirdPartyEmailPasswordAuth>
}
/>
<Route path="/" element={<Component />} />
</Routes>
</div>
</Router>
</SuperTokensWrapper>
</div>
);
}cookieHandlersupertokens-web-jsemailpassword and thirdpartyemailpassword recipestslibemailpassword and thirdpartyemailpassword recipes.emailpassword and thirdpartyemailpassword recipe.emailpassword and thirdpartyemailpassword recipes.setCookieSync and getCookieSync from the interface for cookieHandler when calling SuperTokens.inituser in the following functions to include information returned by the third party providersignInAndUp function for ThirdParty recipethirdPartySignInAndUp function for the ThirdPartyEmailPassword recipethirdPartySignInAndUp function for the ThirdPartyPasswordless recipeuserContext, learn more about this by visiting the advanced cusotmisations section in the documentationuserContext prop, learn more about this by visiting the advanced cusotmisations section in the documentationverifyEmail, sendVerificationEmailsubmitNewPassword, sendPasswordResetEmail, signUp, signIn, doesEmailExist.getAuthorisationURLWithQueryParamsAndSetState, signInAndUp.redirectToThirdPartyLogin from thirdpartyemailpassword recipe.createCode, resendCode, consumeCode, doesEmailExist, doesPhoneNumberExistredirectToThirdPartyLogin, thirdPartySignInAndUp, createCode, resendCode, consumeCode, doesPasswordlessUserEmailExist, doesPasswordlessUserPhoneNumberExistverifyEmail -> No longer accepts token as a parameter, instead it calls getEmailVerificationTokenFromURLgetEmailVerificationTokenFromURL -> NEW FUNCTIONsubmitNewPassword -> No longer accepts token as a parameter, instead calls getResetPasswordTokenFromURLgetResetPasswordTokenFromURL -> NEW FUNCTIONgetOAuthState -> RENAMED TO getStateAndOtherInfoFromStoragesetOAuthState -> RENAMED TO setStateAndOtherInfoToStoragegetOAuthAuthorisationURL -> RENAMED TO getAuthorisationURLFromBackendgetAuthorisationURLWithQueryParamsAndSetState -> NEW FUNCTIONgenerateStateToSendToOAuthProvider -> NEW FUNCTIONverifyAndGetStateOrThrowError -> NEW FUNCTIONgetAuthCodeFromURL -> NEW FUNCTIONgetAuthErrorFromURL -> NEW FUNCTIONgetAuthStateFromURL -> NEW FUNCTIONredirectToThirdPartyLogin -> REMOVED (use getAuthorisationURLWithQueryParamsAndSetState instead). NOTE: If you call this function yourself the SDK will no longer auto-redirect, you will need to redirect to the result url manually.signInAndUp -> REMOVED, this function has been split into 3 new functions for simplicity (explained below)emailPasswordSignUp -> NEW FUNCTIONemailPasswordSignIn -> NEW FUNCTIONthirdPartySignInAndUp -> NEW FUNCTIONgetLinkCodeFromURL -> NEW FUNCTIONgetPreAuthSessionIdFromURL -> NEW FUNCTIONclearLoginAttemptInfo -> RENAMED TO clearPasswordlessLoginAttemptInfopostAPIHook configuration parameter that can be used to respond to network actions.status field along with other properties (instead of returning a boolean directly for example), to make function return types more consistent across recipesdisableDefaultImplementation has been renamed to disableDefaultUI to make the name more accurate to the effect the property has. This is applicable only if you are using the SDK with custom UI and disabling the pre-built UI that SuperTokens provides.fetchResponse field for any function that makes a network request. If you override functions and return a custom object you will need to update your code to include a fetchResponse field that should be a clone of the original response object (Refer to this page)For example if your override looks like this:
import SuperTokens from "supertokens-auth-react";
import EmailPassword from "supertokens-auth-react/recipe/emailpassword";
SuperTokens.init({
appInfo: {
apiDomain: "...",
appName: "...",
websiteDomain: "..."
},
recipeList: [
EmailPassword.init({
override: {
functions: (originalImplementation) => {
return {
...originalImplementation,
signIn: async function (input) {
let response = makeNetworkRequest();
// TODO: some custom logic
return {
status: "OK",
user: {...},
};
},
}
},
}
})
]
});You will need to modify the function like this:
...
signIn: async function (input) {
let response = makeNetworkRequest();
// TODO: some custom logic
return {
status: "OK",
user: {...},
fetchResponse: response.clone()
};
},
...NOTE: If you use the originalImplementation in your overrides, you can access fetchResponse from the returned object
import SuperTokens from "supertokens-auth-react";
import EmailPassword from "supertokens-auth-react/recipe/emailpassword";
SuperTokens.init({
appInfo: {
apiDomain: "...",
appName: "...",
websiteDomain: "..."
},
recipeList: [
EmailPassword.init({
override: {
functions: (originalImplementation) => {
return {
...originalImplementation,
signIn: async function (input) {
let response = await originalImplementation.signIn(input);
// TODO: some custom logic
return {
status: "OK",
user: {...},
fetchResponse: response.fetchResponse;
};
// OR return the default implementation
// return await originalImplementation.signIn(input)
},
}
},
}
})
]
});async function isEmailVerified(input): Promise<boolean> {...}Now returns
async function isEmailVerified(input): Promise<{
status: "OK",
isVerified: boolean,
fetchResponse: Response, // Refer to point above
}> {...}cookieHandler that allows for custom handling when the SDK reads/writes cookieswindowHandler that allows for custom handling when the SDK uses any functions from the Window API.SessionAuth more clear.PasswordlessEmailForm, PasswordlessPhoneForm and PasswordlessEmailOrPhoneForm overridable components._Override now)ThirdPartyEmailPasswordSignInAndUpForm overrideable component (now reusing overrides of the email password recipe)Added defaultCountry to passwordless config input in the EMAIL_OR_PHONE case
add workflow to verify if pr title follows conventional commits
https://supertokens.com?campaign=poweredbyproviderGoogle, providerApple etc..) which super seeds providerButton.getRoutingComponent now returns JSX.Element | null instead of JSX.Element | undefinedproviderGoogle, providerApple etc..) which super seeds providerButton. So if you are using providerButton to change CSS, then you should add a !important to it.@emotion/react already depends on it.redirect_uri third party authorisation URL if it's already set by the backend.clientId input to providers to be sent during the signinup API.bind(this) when calling original implementationgetJWTPayloadSecurely to getAccessTokenPayloadSecurely^9.0.0). It was a breaking change in that, which implies a breaking change here too.UNAUTHORISED event to include the new sessionExpiredOrRevoked property.Uncaught ReferenceError: process is not defined during getting if testing or not.emailVerificationAuth, querying for is email verified only if a session existsuseRef hook when using withRouter so that the underlying component is not unmounted.redirectToPath is "", and we are not using react-router-dom, then we redirect to /, otherwise we might be stuck in an infinite redirect loop.SessionAuth for all our components: https://github.com/supertokens/supertokens-auth-react/issues/241AuthWidgetWrapper component that will redirect login UI if already logged inSessionAuth to be inside another SessionAuth.onSessionExpired optional prop on SessionAuth, EmailPasswordAuth, ThirdPartyAuth and ThirdPartyEmailPasswordAuthIf a component is wrapped in an auth wrapper with requiredAuth={true}, and onSessionExpired is not provided, then the user will be automatically redirected to the login screen in case of session expiry.
The components override API has changed from (DefaultComponent) => (props) => React.Element to ({ DefaultComponent, …props }) => React.Element.
disableEmailPassword config provided to thirdpartyemailpasswordsignInAndUpFeature config optional in thirdpartyemailpassword.initsetAuth0API and getAuth0APIGET_REDIRECTION_URL from the possible action types for getRedirectionURL.redirectToAuth to take an object and adds redirectBack param, which can be used to indicate if the user should be redirected to the current page.getRefreshURLDomain function from session recipe.SIGN_OUT even and pre API hook into the Session recipe.preAPIHook functionSIGN_IN, SIGN_UP Pre API hook action to EMAIL_PASSWORD_SIGN_IN, EMAIL_PASSWORD_SIGN_UP or THIRD_PARTY_SIGN_IN_UPcookieDomain in config to add interceptors to multiple API subdomain: https://github.com/supertokens/supertokens-website/issues/58getSuperTokensRoutesForReactRouterDom, use it like getSuperTokensRoutesForReactRouterDom(require("react-router-dom"))useReactRouterDom is no longer required. React router dom is enabled only if the user uses getSuperTokensRoutesForReactRouterDom.rid on each request - acts as a CSRF protection measure (see https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#use-of-custom-request-headers)apiGatewayPath in appInfo. Related to https://github.com/supertokens/supertokens-core/issues/234SessionAuth wrapperrequireAuth boolean to all Auth wrappers to protect pages optionallygetUserId and doesSessionExist returning PromisesredirectToAuth function for all auth recipes({RequestInit, action}) => Promise<RequestInit> to ({url, RequestInit, action}) => Promise<RequestInit | {RequestInit, url}>{action: "SIGN_IN_COMPLETE" | "SIGN_UP_COMPLETE"} to {action: "SUCCESS", isNewUser: boolean}useReactRouterDom.DefaultToSignUp config and default widget to sign up form.