fix(deps): update dependency supertokens-web-js to v0.15.0

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
supertokens-web-js	0.5.0 -> 0.15.0

---

Release Notes

supertokens/supertokens-web-js (supertokens-web-js)

v0.15.0

Compare Source

• Added Webauthn recipe to support logins using WebAuthN (Passkeys)
• Updated User type to include webauthn as a possible login method.
• Added support for FDI 4.1

v0.14.0

Compare Source

• Added the OAuth2Provider recipe

Breaking changes

• Now only supporting FDI 3.1 and 4.0 (Node >= 21.0.0)
• Added a new shouldTryLinkingToSessionUser flag to sign in/up related function inputs:
  • No action is needed if you are not using MFA/session based account linking.
  • If you are implementing MFA:
    • Plase set this flag to false (or leave as undefined) during first factor sign-ins
    • Please set this flag to true for secondary factors.
    • Please forward this flag to the original implementation in any of your overrides.
  • Changed functions:
    • EmailPassword.signIn, EmailPassword.signUp: both override and callable functions
    • ThirdParty.getAuthorisationURLWithQueryParamsAndSetState: both override and callable function
    • Passwordless:
      • Functions overrides: consumeCode, resendCode, createCode, setLoginAttemptInfo, getLoginAttemptInfo
      • Calling createCode and setLoginAttemptInfo take this flag as an optional input (it defaults to false)
• Changed the default implementation of getTenantId to default to the tenantId query parameter (if present) then falling back to the public tenant instead of always defaulting to the public tenant
• We now disable session based account linking in the magic link based flow in passwordless by default
  • This is to make it function more consistently instead of only working if the link was opened on the same device
  • You can override by overriding the consumeCode function in the Passwordless Recipe (see in the Migration guide section below for more information)

Migration guide

Session based account linking for magic link based flows

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 });
                },
            };
        },
    },
});

v0.13.1

Compare Source

• Changes bundle file names to include a hash.

v0.13.0

Compare Source

Breaking Changes

• Removes the default maxAgeInSeconds value (previously 300 seconds) in EmailVerification Claim. If the claim value is true and maxAgeInSeconds is not provided, it will not be refreshed.

v0.12.0

Compare Source

Breaking Changes

• Removed ThirdPartyEmailPassword and ThirdPartyPasswordless recipes
• Dropped support for FDI version 1.X
• Added support for FDI version 2.0 and 3.0
• Removed createCode, resendCode and consumeCode from the exports of recipe/passwordless/utils
• Added the SESSION_ALREADY_EXISTS event to the session recipe. This is used by our pre-built UI.

Migration guide

• 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.

v0.11.0

Compare Source

Breaking changes

The shouldDoInterceptionBasedOnUrl function now returns true:

• If sessionTokenBackendDomain is a valid subdomain of the URL's domain. This aligns with the behavior of browsers when sending cookies to subdomains.
• Even if the ports of the URL you are querying are different compared to the apiDomain's port ot the sessionTokenBackendDomain port (as long as the hostname is the same, or a subdomain of the sessionTokenBackendDomain): #​217

v0.10.1

Compare Source

Fixes

• Reduced the number of unnecessary email verification checks by fixing the default values for refetchTimeOnFalseInSeconds and maxAgeInSeconds

v0.10.0

Compare Source

Overview

Introducing multi-factor authentication

With this release, we are introducing MultiFactorAuthentication and TOTP, this will let you:

• require (2FA or MFA) during sign in
• make use of our TOTP

Check our guide for more information.

Changes

• Added support for FDI 1.19 (Node SDK>= 17.0.0), but keeping support FDI version 1.17 and 1.18 (node >= 15.0.0, golang>=0.13, python>=0.15.0)
• Added the MultiFactorAuth and TOTP recipes. To start using them you'll need compatible versions:
  • Core>=8.0.0
  • supertokens-node>=17.0.0
  • supertokens-website>=18.0.0
  • supertokens-web-js>=0.10.0
  • supertokens-auth-react>=0.39.0

Breaking changes

• Added firstFactors into the return type of getLoginMethods and removed the enabled flags of different login methods.
  • For older FDI versions, the firstFactors array will be calculated based on those enabled flags.
• Renamed validatorId in claim validation errors to id to match the backend SDKs

Migration guide

getLoginMethods interface change

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
    }
}

Renamed validatorId

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);
    }
}

v0.9.2

Compare Source

What's Changed

• fix: emailverification validator refetch times (0.9) by @​anku255 in https://github.com/supertokens/supertokens-web-js/pull/111
• fix: supertokens-website version by @​anku255 in https://github.com/supertokens/supertokens-web-js/pull/112

Full Changelog: supertokens/supertokens-web-js@v0.10.1...v0.9.2

v0.9.1

Compare Source

Changes

• Added dateprovider.js bundle file to enable importing DateProvider via a script tag

v0.9.0

Compare Source

v0.8.0

Compare Source

Overview

Introducing account-linking

With this release, we are introducing AccountLinking, this will let you:

• link accounts automatically,
• implement manual account linking flows.

Check our guide for more information.

To use this you'll need compatible versions:

• Core>=7.0.0
• supertokens-node>=16.0.0 (support is pending in other backend SDKs)
• supertokens-website>=17.0.3
• supertokens-web-js>=0.8.0
• supertokens-auth-react>=0.35.0

Breaking changes

• Added support for FDI 1.18 (Node SDK>= 16.0.0), but keeping support FDI version1.17 (node >= 15.0.0, golang>=0.13, python>=0.15.0)
• User type has changed across recipes and functions: recipe specific user types have been removed and replaced by a generic one that contains more information
• createdNewUser has been renamed to createdNewRecipeUser
• createCode, consumeCode, createPasswordlessCode and consumePasswordlessCode can now return status: SIGN_IN_UP_NOT_ALLOWED
• signInAndUp and thirdPartySignInAndUp can now return new status: SIGN_IN_UP_NOT_ALLOWED
• sendPasswordResetEmail can now return status: "PASSWORD_RESET_NOT_ALLOWED"
• signIn and emailPasswordSignIn can now return SIGN_IN_NOT_ALLOWED
• signUp and emailPasswordSignUp can now return SIGN_UP_NOT_ALLOWED

Migration

New User structure

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.id
• user.email becomes user.emails[0]
• user.phoneNumber becomes user.phoneNumbers[0]
• user.thirdParty becomes user.thirdParty[0]
• user.timeJoined is still user.timeJoined
• user.tenantIds is still user.tenantIds

Checking if a user signed up or signed in

• When calling passwordless consumeCode / social login signinup APIs, you can check if a user signed up by:

    // Here res refers to the result the function/api functions mentioned above.
    const isNewUser = res.createdNewRecipeUser && res.user.loginMethods.length === 1;

• When calling the emailpassword sign up API, you can check if a user signed up by:

    const isNewUser = res.user.loginMethods.length === 1;

v0.7.3

Compare Source

Fixes

• Fixed clientType usage in thirdpartypasswordless

v0.7.2

Compare Source

Fixes

• Fixed clientType usage in thirdpartyemailpassword and thirdpartypasswordless

v0.7.1

Compare Source

Changes

• Removed unused tenant id param from isEmailVerified and sendVerificationEmail requests

v0.7.0

Compare Source

Added

• Multitenancy recipe
• Added an overrideable getTenantIdFromURL to multiple recipes
• Optional clientType config in the input for SuperTokens.init function, that is used by thirdparty and multitenancy recipes.

Breaking changes

• Only supporting FDI 1.17
• Backend SDKs have to be updated first to a version that supports multi-tenancy for thirdparty
  • supertokens-node: >= 15.0.0
  • supertokens-golang: >= 0.13.0
  • supertokens-python: >= 0.15.0
• In ThirdParty recipe,
  • Changed signatures of the functions getAuthorisationURLWithQueryParamsAndSetState
  • Removed functions - setStateAndOtherInfoToStorage, getAuthorisationURLFromBackend, generateStateToSendToOAuthProvider, verifyAndGetStateOrThrowError, getAuthCodeFromURL, getAuthErrorFromURL, getAuthStateFromURL
• In ThirdPartyEmailpassword recipe,
  • Changed signatures of the functions getAuthorisationURLWithQueryParamsAndSetState
  • Removed functions - setStateAndOtherInfoToStorage, getAuthorisationURLFromBackend, generateStateToSendToOAuthProvider, verifyAndGetStateOrThrowError, getAuthCodeFromURL, getAuthErrorFromURL, getAuthStateFromURL
• In ThirdPartyPasswordless recipe,
  • Changed signatures of the functions getThirdPartyAuthorisationURLWithQueryParamsAndSetState
  • Removed functions - setThirdPartyStateAndOtherInfoToStorage, getAuthorisationURLFromBackend, generateThirdPartyStateToSendToOAuthProvider, verifyAndGetThirdPartyStateOrThrowError, getThirdPartyAuthCodeFromURL, getThirdPartyAuthErrorFromURL, getThirdPartyAuthStateFromURL

Changes

• Updates dependencies and backend config for the vue with-thirdpartyemailpassword example app

Migration

Renamed parameters in getAuthorisationURLWithQueryParamsAndSetState

Before:

    const authUrl = await ThirdPartyEmailPassword.getAuthorisationURLWithQueryParamsAndSetState({
        providerId: "google",
        authorisationURL: `${websiteDomain}/auth/callback/google`,
    });

After:

    const authUrl = await ThirdPartyEmailPassword.getAuthorisationURLWithQueryParamsAndSetState({
        thirdPartyId: "google",
        frontendRedirectURI: `${websiteDomain}/auth/callback/google`,
    });

If the provider is redirecting to the backend directly (i.e.: Apple)

Before:

    const authUrl = await ThirdPartyEmailPassword.getAuthorisationURLWithQueryParamsAndSetState({
        providerId: "apple",
        authorisationURL: `${websiteDomain}/auth/callback/apple`,
    });

After:

    const authUrl = await ThirdPartyEmailPassword.getAuthorisationURLWithQueryParamsAndSetState({
        thirdPartyId: "apple",
        frontendRedirectURI: `${websiteDomain}/auth/callback/apple`,
        redirectURIOnProviderDashboard: `${apiDomain}/auth/callback/apple`
    });

v0.6.0

Compare Source

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.