supertokens-web-js
Advanced tools
Changelog
[0.14.0] - 2024-10-07
shouldTryLinkingToSessionUser
flag to sign in/up related function inputs:
false
(or leave as undefined) during first factor sign-instrue
for secondary factors.EmailPassword.signIn
, EmailPassword.signUp
: both override and callable functionsThirdParty.getAuthorisationURLWithQueryParamsAndSetState
: both override and callable functionPasswordless
:
consumeCode
, resendCode
, createCode
, setLoginAttemptInfo
, getLoginAttemptInfo
createCode
and setLoginAttemptInfo
take this flag as an optional input (it defaults to false)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 Recipe (see in the Migration guide section below for more information)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 });
},
};
},
},
});
Changelog
[0.13.1] - 2024-10-08
Changelog
[0.13.0] - 2024-07-10
maxAgeInSeconds
value (previously 300 seconds) in EmailVerification Claim. If the claim value is true and maxAgeInSeconds
is not provided, it will not be refreshed.Changelog
[0.12.0] - 2024-05-24
createCode
, resendCode
and consumeCode
from the exports of recipe/passwordless/utils
SESSION_ALREADY_EXISTS
event to the session recipe. This is used by our pre-built UI.If 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.
Changelog
[0.11.0] - 2024-05-09
The shouldDoInterceptionBasedOnUrl
function now returns true:
Changelog
[0.10.1] - 2024-04-08
refetchTimeOnFalseInSeconds
and maxAgeInSeconds
Changelog
[0.10.0] - 2024-03-03
With this release, we are introducing MultiFactorAuthentication and TOTP, this will let you:
Check our guide for more information.
MultiFactorAuth
and TOTP
recipes. To start using them you'll need compatible versions:
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 SDKsIf 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
}
}
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);
}
}
Changelog
[0.9.1] - 2024-02-07
dateprovider.js
bundle file to enable importing DateProvider
via a script tagChangelog
[0.9.0] - 2024-01-18
DateProvider
implementation relies on localStorage
. If your environment lacks support for localStorage
, you must provide custom implementations for either the DateProvider
or localStorage
.EmailVerificationClaim
now uses DateProvider
to account for clock skew.DateProvider
from supertokens-website, 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.