chore(deps): update supertokens (major)

[renovate]

This PR contains the following updates:

Package	Type	Update	Change	Age	Adoption	Passing	Confidence
registry.supertokens.io/supertokens/supertokens-postgresql		major	7.0 -> 9.0
supertokens-node	devDependencies	major	15.2.1 -> 18.0.0

---

Release Notes

supertokens/supertokens-node (supertokens-node)

v18.0.0

Compare Source

Breaking change

• Removed ThirdPartyEmailPassword and ThirdPartyPasswordless recipes. Instead, you should use ThirdParty + EmailPassword or ThirdParty + Passwordless recipes separately in your recipe list.
• Removed rid query param from:
  • email verification links
  • passwordless magic links
  • password reset links
• The API for checking if an email exists in the passwordless recipe has changed to return true only if there exists a user with that email as a passwordless user. So for example, earlier, if a user existed with email test@example.com as an emailpassword user (and not passwordless user), the passwordless API for does email exist would return true, but now, it won't.

Changes

• Even if the rid header is present in an API call, the routing now not only depends on that. If the SDK cannot resolve a request handler based on the rid, request path and method, it will try to resolve a request handler only based on the request path and method (therefore ignoring the rid header).
• New API handlers are:
  • GET /emailpassword/email/exists => email password, does email exist API (used to be GET /signup/email/exists with rid of emailpassword or thirdpartyemailpassword which is now deprecated)
  • GET /passwordless/email/exists => email password, does email exist API (used to be GET /signup/email/exists with rid of passwordless or thirdpartypasswordless which is now deprecated)
  • GET /passwordless/phonenumber/exists => email password, does email exist API (used to be GET /signup/phonenumber/exists which is now deprecated)
• Support for FDI 2.0 and 3.0

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.

Fixes

• Fixes override recursion build-up in built-in providers due to the modification of the input.override object in the ThirdParty providers list.
• Fixes issue with reference to config object in TypeProvider in the provider override. The issue was the originalImplementation.config object did not have the updated config values that was being used in the provider implementation.

v17.1.3

Compare Source

What's Changed

• fix: thirdparty recursion and config reference issues by @​sattvikc in https://github.com/supertokens/supertokens-node/pull/842

Full Changelog: supertokens/supertokens-node@v17.1.2...v17.1.3

v17.1.2

Compare Source

Fixes

• Add workaround for unsupported 'cache' field in Cloudflare Workers. We retry fetch requests without the 'cache' field if they fail due to it not being implemented.

v17.1.1

Compare Source

Fixes

• Fixed an issue when using Apple as a third party provider with our NextJs integration.
• Added a compatibility layer into BaseRequest to handle the form data parser returning FormData instead of the raw parsed object. This is to address/fix the above issues, possibly present in other frameworks.

v17.1.0

Compare Source

• Added olderCookieDomain config option in the session recipe. This will allow users to clear cookies from the older domain when the cookieDomain is changed.
• If verifySession detects multiple access tokens in the request, it will return a 401 error, prompting a refresh, even if one of the tokens is valid.
• refreshPOST (/auth/session/refresh by default) API changes:
  • now returns 500 error if multiple access tokens are present in the request and config.olderCookieDomain is not set.
  • now clears the access token cookie if it was called without a refresh token (if an access token cookie exists and if using cookie-based sessions).
  • now clears cookies from the old domain if olderCookieDomain is specified and multiple refresh/access token cookies exist, without updating the front-token or any of the tokens.
  • now a 200 response may not include new session tokens.

Rationale

This update addresses an edge case where changing the cookieDomain config on the server can lead to session integrity issues. For instance, if the API server URL is 'api.example.com' with a cookie domain of '.example.com', and the server updates the cookie domain to 'api.example.com', the client may retain cookies with both '.example.com' and 'api.example.com' domains, resulting in multiple sets of session token cookies existing.

Previously, verifySession would select one of the access tokens from the incoming request. If it chose the older cookie, it would return a 401 status code, prompting a refresh request. However, the refreshPOST API would then set new session token cookies with the updated cookieDomain, but older cookies will persist, leading to repeated 401 errors and refresh loops.

With this update, verifySession will return a 401 error if it detects multiple access tokens in the request, prompting a refresh request. The refreshPOST API will clear cookies from the old domain if olderCookieDomain is specified in the configuration, then return a 200 status. If olderCookieDomain is not configured, the refreshPOST API will return a 500 error with a message instructing to set olderCookieDomain.

Example:

• apiDomain: 'api.example.com'
• cookieDomain: 'api.example.com'

Flow:

1. After authentication, the frontend has cookies set with domain=api.example.com, but the access token has expired.
2. The server updates cookieDomain to .example.com.
3. An API call requiring session with an expired access token (cookie with domain=api.example.com) results in a 401 response.
4. The frontend attempts to refresh the session, generating a new access token saved with domain=.example.com.
5. The original API call is retried, but because it sends both the old and new cookies, it again results in a 401 response.
6. The frontend tries to refresh the session with multiple access tokens: - If olderCookieDomain is not set, the refresh fails with a 500 error. - The user remains stuck until they clear cookies manually or olderCookieDomain is set. - If olderCookieDomain is set, the refresh clears the older cookie, returning a 200 response. - The frontend retries the original API call, sending only the new cookie (domain=.example.com), resulting in a successful request.

v17.0.7

Compare Source

• Adds no-cache header when querying core, so that frameworks like NextJS don't cache GET requests (https://nextjs.org/docs/app/building-your-application/caching#data-cache)

v17.0.6

Compare Source

• Fixes how FDI header is parsed from frontend requests to account for more than one version being passed.

v17.0.5

Compare Source

• Support for websiteDomain / apiDomain ending with .local: https://github.com/supertokens/supertokens-node/issues/823

v17.0.4

Compare Source

Changes

• Improved error message to help debugging if MFA was enabled without account linking.
• Now the resyncSessionAndFetchMFAInfoPUT will throw if the user is in a stuck state, because they are required to complete factors, but they are not allowed to because of some configuration issue.

v17.0.3

Compare Source

Fixes

• Smaller fixes in Passwordless:
  • Fixed an issue in createCodePOST where the flowtype wasn't appropriately set in some MFA cases
  • Fixed an interaction with the firstFactors config of the MultiFactorAuth recipe in createCodePOST
  • Fixed an issue in resendCodePOST where the email/text message included a magic link when it shouldn't have in some MFA cases

v17.0.2

Compare Source

• Remove tenants listing dashboard API and update getTenantLoginMethodsInfo dashboard API to remove querying core in loop and return only firstFactors.

v17.0.1

Compare Source

Changes

• We now allow sign in/up even if the session user is conflicting with the current sign in/up (because of the email verification status)
  • This makes use-cases where an secondary factor (i.e.: otp-email) is also used as a means of verification.

v17.0.0

Compare Source

Changes

• Enable smooth switching between useDynamicAccessTokenSigningKey settings by allowing refresh calls to change the signing key type of a session
• Added a core call cache that should reduce traffic to your SuperTokens core instances
• Refactored sign in/up API codes to reduce code duplication
• Added MFA related information to dashboard APIs
• Added a cache to reduce the number of requests made to the core. This can be disabled using the disableCoreCallCache: true, in the config.
• Added new overwriteSessionDuringSignInUp configuration option to the Session recipe
• Added new function: checkCode to Passwordless and ThirdPartyPasswordless recipes
• Added new function: verifyCredentials to EmailPassword and ThirdPartyEmailPassword recipes
• 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

• Now only supporting CDI 5.0. Compatible with core version >= 8.0
• Account linking now takes the active session into account.
• Account linking now also happens in sign in function calls (instead of sign ups and sign in API calls)
• Fixed the typing of the userContext:
  • All functions now take Record<string, any> instead of any as userContext. This means that primitives (strings, numbers) are no longer allowed as userContext.
  • All functions overrides that take a userContext parameter now get a well typed userContext parameter ensuring that the right object is passed to the original implementation calls
• Calling sign in/up APIs with a session will now skip creating a new session by default. This is overrideable through by passing overwriteSessionDuringSignInUp: true to the Session recipe config.
• Added new support codes to sign in/up APIs. This means that there are new possible values coming from the default implementation for the reason strings of SIGN_IN_NOT_ALLOWED, SIGN_UP_NOT_ALLOWED and SIGN_IN_UP_NOT_ALLOWED responses.
• Session recipe:
  • The sign out API new returns a 401 instead of 200 in case the input access token has expired or is missing.
• AccountLinking recipe:
  • Changed the signature of the following functions, each taking a new (optional) session parameter:
    • createPrimaryUserIdOrLinkAccounts
    • isSignUpAllowed
    • isSignInAllowed
    • isEmailChangeAllowed
  • Changed the signature of the shouldDoAutomaticAccountLinking callback: it now takes a new (optional) session parameter.
• EmailPassword:
  • Changed the signature of the following overrideable functions:
    • signUp
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
    • signIn
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
  • Changed the signature of overrideable APIs, adding a new (optional) session parameter:
    • signInPOST
    • signUpPOST
  • Changed the signature of functions:
    • signUp
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
    • signIn
      • Takes a new (optional) session parameter
      • Can now return with `status: "LINKING_TO_SESSION_USER_FAILED"
• Multitenancy:
  • Changed the signature of the following functions:
    • createOrUpdateTenant: Added optional firstFactors and requiredSecondaryFactors parameters.
    • getTenant: Added firstFactors and requiredSecondaryFactors to the return type
    • listAllTenants: Added firstFactors and requiredSecondaryFactors to the returned tenants
  • Changed the signature of the following overrideable functions:
    • createOrUpdateTenant: Now gets optional firstFactors and requiredSecondaryFactors in the input.
    • getTenant: Added firstFactors and requiredSecondaryFactors to the return type
    • listAllTenants: Added firstFactors and requiredSecondaryFactors to the returned tenants
  • Changed the signature of the overrideable apis:
    • loginMethodsGET: Now returns firstFactors
• Passwordless:
  • revokeCode (and the related overrideable func) can now be called with either preAuthSessionId or codeId instead of only codeId.
  • Added new email and sms type for MFA
  • Changed the signature of the following functions:
    • signInUp, createCode: Takes a new (optional) session parameter
    • consumeCode:
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
      • It now also returns consumedDevice if the code was successfully consumed
  • Changed the signature of the following overrideable functions:
    • createCode: Takes a new (optional) session parameter
    • consumeCode:
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
      • It now also returns consumedDevice if the code was successfully consumed
  • Changed the signature of overrideable APIs, adding a new (optional) session parameter:
    • createCodePOST
    • resendCodePOST
    • consumeCodePOST
• Session claims:
  • The build function and the fetchValue callback of session claims now take a new currentPayload param.
    • This affects built-in claims: EmailVerificationClaim, UserRoleClaim, PermissionClaim, AllowedDomainsClaim.
    • This will affect all custom claims as well built on our base classes.
• ThirdParty:
  • Changed the signature of the following functions:
    • manuallyCreateOrUpdateUser:
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
  • Changed the signature of the following overrideable functions:
    • signInUp:
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
    • manuallyCreateOrUpdateUser
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
  • Changed the signature of overrideable APIs, adding a new (optional) session parameter:
    • signInUpPOST
• ThirdPartyEmailPassword:
  • Added new function: emailPasswordVerifyCredentials
  • Changed the signature of the following functions:
    • thirdPartyManuallyCreateOrUpdateUser:
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
    • emailPasswordSignUp
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
  • Changed the signature of the following overrideable functions:
    • thirdPartySignInUp:
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
    • thirdPartyManuallyCreateOrUpdateUser
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
    • emailPasswordSignUp
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
  • Changed the signature of overrideable APIs, adding a new (optional) session parameter:
    • emailPasswordSignInPOST
    • emailPasswordSignUpPOST
    • thirdPartySignInUpPOST
• ThirdPartyPasswordless:
  • revokeCode (and the related overrideable func) can now be called with either preAuthSessionId or codeId instead of only codeId.
  • Changed the signature of the following functions:
    • thirdPartyManuallyCreateOrUpdateUser:
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
    • passwordlessSignInUp, createCode: Takes a new (optional) session parameter
    • consumeCode:
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
      • It now also returns consumedDevice if the code was successfully consumed
  • Changed the signature of the following overrideable functions:
    • thirdPartySignInUp:
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
    • thirdPartyManuallyCreateOrUpdateUser
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
    • createCode: Takes a new (optional) session parameter
    • consumeCode:
      • Takes a new (optional) session parameter
      • Can now return with status: "LINKING_TO_SESSION_USER_FAILED"
      • It now also returns consumedDevice if the code was successfully consumed
  • Changed the signature of overrideable APIs, adding a new (optional) session parameter:
    • thirdPartySignInUpPOST
    • createCodePOST
    • resendCodePOST
    • consumeCodePOST

Migration guide

shouldDoAutomaticAccountLinking signature change

If you use the userContext or tenantId parameters passed to shouldDoAutomaticAccountLinking, please update your implementation to account for the new parameter.

Before:

AccountLinking.init({
    shouldDoAutomaticAccountLinking: async (newAccountInfo, user, tenantId, userContext) => {
        return {
            shouldAutomaticallyLink: true,
            shouldRequireVerification: true,
        };
    },
});

After:

AccountLinking.init({
    shouldDoAutomaticAccountLinking: async (newAccountInfo, user, session, tenantId, userContext) => {
        return {
            shouldAutomaticallyLink: true,
            shouldRequireVerification: true,
        };
    },
});

Optional session parameter added to public functions

We've added a new optional session parameter to many function calls. In all cases, these have been added as the last parameter before userContext, so this should only affect you if you are using that. You only need to pass a session as a parameter if you are using account linking and want to try and link the user signing in/up to the session user.
You can get the necessary session object using verifySession in an API call.

Here we use the example of EmailPassword.signIn but this fits other functions with changed signatures.

Before:

const signInResp = await EmailPassword.signIn("public", "asdf@asdf.asfd", "testpw", { myContextVar: true });

After:

const signInResp = await EmailPassword.signIn("public", "asdf@asdf.asfd", "testpw", undefined, { myContextVar: true });

fetchValue signature change

If you use the userContext parameter passed to fetchValue, please update your implementation to account for the new parameter.

Before:

const boolClaim = new BooleanClaim({
    key: "asdf",
    fetchValue: (userId, recipeUserId, tenantId, userContext) => {
        return userContext.claimValue;
    },
});

After:

const boolClaim = new BooleanClaim({
    key: "asdf",
    fetchValue: (userId, recipeUserId, tenantId, currentPayload, userContext) => {
        return userContext.claimValue;
    },
});

build signature change

If you were using the build function for custom or built-in session claims, you should update the call signature to also pass the new parameter.

Before:

Session.init({
    override: {
        functions: (originalImplementation) => {
            return {
                ...originalImplementation,
                createNewSession: async function (input) {
                    input.accessTokenPayload = {
                        ...input.accessTokenPayload,
                        ...(await UserRoleClaim.build(
                            input.userId,
                            input.recipeUserId,
                            input.tenantId,
                            input.userContext
                        )),
                    };

                    return originalImplementation.createNewSession(input);
                },
            };
        },
    },
});

After:

Session.init({
    override: {
        functions: (originalImplementation) => {
            return {
                ...originalImplementation,
                createNewSession: async function (input) {
                    input.accessTokenPayload = {
                        ...input.accessTokenPayload,
                        ...(await UserRoleClaim.build(
                            input.userId,
                            input.recipeUserId,
                            input.tenantId,
                            input.accessTokenPayload,
                            input.userContext
                        )),
                    };

                    return originalImplementation.createNewSession(input);
                },
            };
        },
    },
});

Post sign-in/up actions

Since now sign in/up APIs and functions can be called with a session (e.g.: during MFA flows), you may need to add an extra check to your overrides to account for that:

Before:

// While this example uses Passwordless, all recipes require a very similar change
Passwordless.init({
    contactMethod: "EMAIL", // This example will work with any contactMethod
    flowType: "USER_INPUT_CODE_AND_MAGIC_LINK", // This example will work with any flowType

    override: {
        functions: (originalImplementation) => {
            return {
                ...originalImplementation,
                consumeCode: async (input) => {

                    // First we call the original implementation of consumeCode.
                    let response = await originalImplementation.consumeCode(input);

                    // Post sign up response, we check if it was successful
                    if (response.status === "OK") {
                        if (response.createdNewRecipeUser && response.user.loginMethods.length === 1) {
                            // TODO: post sign up logic
                        } else {
                            // TODO: post sign in logic
                        }
                    }
                    return response;
                }
            }
        }
    }
}),

After:

// While this example uses Passwordless, all recipes require a very similar change
Passwordless.init({
    contactMethod: "EMAIL", // This example will work with any contactMethod
    flowType: "USER_INPUT_CODE_AND_MAGIC_LINK", // This example will work with any flowType

    override: {
        functions: (originalImplementation) => {
            return {
                ...originalImplementation,
                consumeCode: async (input) => {

                    // First we call the original implementation of consumeCode.
                    let response = await originalImplementation.consumeCode(input);

                    // Post sign up response, we check if it was successful
                    if (response.status === "OK") {
                        if (input.session === undefined) {
                            if (response.createdNewRecipeUser && response.user.loginMethods.length === 1) {
                                // TODO: post sign up logic
                            } else {
                                // TODO: post sign in logic
                            }
                        }
                    }
                    return response;
                }
            }
        }
    }
}),

Sign-in/up linking to the session user

Sign in/up APIs and functions will now attempt to link the authenticating user to the session user if a session is available (depending on AccountLinking settings). You can disable this and get the old behaviour by:

Before:

// While this example uses Passwordless, all recipes require a very similar change
Passwordless.init({
    contactMethod: "EMAIL", // This example will work with any contactMethod
    flowType: "USER_INPUT_CODE_AND_MAGIC_LINK", // This example will work with any flowType
}),

After:

// While this example uses Passwordless, all recipes require a very similar change
Passwordless.init({
    contactMethod: "EMAIL", // This example will work with any contactMethod
    flowType: "USER_INPUT_CODE_AND_MAGIC_LINK", // This example will work with any flowType

    override: {
        functions: (originalImplementation) => {
            return {
                ...originalImplementation,
                consumeCode: async (input) => {
                    input.session = undefined;
                    return originalImplementation.consumeCode(input);
                }
            }
        }
    }
}),

v16.7.6

Compare Source

What's Changed

• fix: thirdparty recursion and config reference issues by @​sattvikc in https://github.com/supertokens/supertokens-node/pull/843
• fix: comments and circleci by @​sattvikc in https://github.com/supertokens/supertokens-node/pull/845

Full Changelog: supertokens/supertokens-node@v16.7.5...v16.7.6

v16.7.5

Compare Source

What's Changed

• fix: backports for core 8.0 by @​sattvikc in https://github.com/supertokens/supertokens-node/pull/809

Full Changelog: supertokens/supertokens-node@v17.0.2...v16.7.5

v16.7.4

Compare Source

• Adds a user friendly error screen that provides helpful information regarding Content Security Policy (CSP) issues..

v16.7.3

Compare Source

• Fixes dashboard URI path. Now it returns the complete user given path instead of just the normalized connectionURI domain.

v16.7.2

Compare Source

• createNewSession now defaults to the value of the st-auth-mode header (if available) if the configured getTokenTransferMethod returns any.

v16.7.1

Compare Source

• Fixes type output of resetPasswordUsingToken in emailpassword and thirdpartyemailpassword recipe to not include statuses that happen based on email change.

v16.7.0

Compare Source

• Add session util functions withSession, getSSRSession and withPreParsedRequestResponse for Next.js App directory.
• Previously, the custom framework's errorHandler callback function was invoked only upon encountering an error. This behavior has been rectified, and now the callback is invoked in both error and success cases.
• Added user creation apis on dashboard recipe to create Emailpassword and Passwordless recipe users.

v16.6.8

Compare Source

• Fix App dir support by removing the import of the "http" module

v16.6.7

Compare Source

• Adds facebook user data by checking the scopes provided in the config

v16.6.6

Compare Source

• Adds userContext input to the validate function in form fields. You can use this to fetch the request object from the userContext, read the request body, and then read the other form fields from there. If doing so, keep in mind that for the email and password validators, the request object may not always be available in the validate function, and even if it's available, it may not have the request body of the sign up API since the validate functions are also called from other operations (like in password reset API). For custom form fields that you have added to the sign up API, the request object will always be there in the userContext.
• Fixes support for the custom framework on node 16 by optionally using an implementation of the Headers class (from node-fetch)

v16.6.5

Compare Source

• CI/CD changes
• Fixes connectionURI domain normalisation.

v16.6.4

Compare Source

• Fixes typing of verifySession adding generic to extend the fastify base request.

v16.6.3

Compare Source

• Fixes issue with LinkedIn OAuth (#​751)

v16.6.2

Compare Source

• Fixes implementation of getBackwardsCompatibleUserInfo to not throw an error in case of session and user id mismatch.

v16.6.1

Compare Source

• Removed dependency on the crypto library to enable Apple OAuth usage in Cloudflare Workers.

v16.6.0

Compare Source

Added

• Added User roles and permissions feature to dashboard recipe.

v16.5.2

Compare Source

• Fixes issue with passwordReset in emailpassword recipe for custom frameworks (#​746)

v16.5.1

Compare Source

• Fixes issue with createResetPasswordLink and sendResetPasswordEmail in thirdpartyemailpassword recipe.

v16.5.0

Compare Source

• Added networkInterceptor to the TypeInput config.
  • This can be used to capture/modify all the HTTP requests sent to the core.
  • Closes the issue - https://github.com/supertokens/supertokens-core/issues/865

v16.4.0

Compare Source

• Added debug property to TypeInput. When set to true, it will enable debug logs.

v16.3.4

Compare Source

Fixes

• Fixes an issue where sometimes the Access-Control-Expose-Headers header value would contain duplicates

v16.3.3

Compare Source

• Tests null values in ProviderConfig saved in core

v16.3.2

Compare Source

Fixes

• getUsersNewestFirst and getUsersOldestFirst will now properly filter users by tenantId.
• Fixes issue with missed email verification claim update that caused the frontend pre built UI to call the email verify API multiple times.

v16.3.1

Compare Source

Fixes

• Handle AWS Public URLs (ending with .amazonaws.com) separately while extracting TLDs for SameSite attribute.

v16.3.0

Compare Source

Added

• Adds support for configuring multiple frontend domains to be used with the same backend
• Added a new origin property to appInfo, this can be configured to be a function which allows you to conditionally return the value of the frontend domain. This property will replace websiteDomain in a future release of supertokens-node
• websiteDomain inside appInfo is now optional. Using origin is recommended over using websiteDomain. This is not a breaking change and using websiteDomain will continue to work
• Added a "custom" framework you can use in framework normally not supported by our SDK
• Added a next13 app router compatible request handler.

Fixed

• Fixed an issue where calling signinup for thirdparty recipe would result in a "clone is not a function" error

Changes

• Using built-in fetch whenever available instead of cross-fetch
• Improved edge-function support

v16.2.1

Compare Source

• Slight refactors logic to code for social providers to make it consistent across all providers

v16.2.0

Compare Source

Changes

• Added validateAccessToken to the configuration for social login providers, this function allows you to verify the access token returned by the social provider. If you are using Github as a provider, there is a default implmentation provided for this function.

v16.1.0

Compare Source

• Added twitter as a built-in thirdparty provider

v16.0.0

Compare Source

Overview

Introducing account-linking

With this release, we are introducing a new AccountLinking recipe, 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

The new User object and primary vs non-primary users

In this release, we've removed the recipes specific user types and instead introduced a new User class to support the "Primary user" concept introduced by account linking

• The new User class now provides the same interface for all recipes.
• It contains an isPrimary field that you can use to differentiate between primary and recipe users
• The loginMethods array contains objects that covers all props of the old (recipe specific) user types, with the exception of the id. Please check the migration section below to get the exact mapping between old and new props.
• Non-primary users:
  • The loginMethods array should contain exactly 1 element.
  • user.id will be the same as user.loginMethods[0].recipeUserId.getAsString().
  • user.id will change if it is linked to another user.
  • They can become a primary user if, and only if there are no other primary users with the same email, third party info or phone number as this user across all the tenants that this user is a part of.
• Primary users
  • The loginMethods array can have 1 or more elements, each corresponding to a single recipe user.
  • user.id will not change even if other users are linked to it.
  • Other non-primary users can be linked to it. The user ID of the linked accounts will now be the primary users ID.
• Check here for more information about differences between primary and recipe users.

Primary vs RecipeUserId

Because of account linking we've introduced a new Primary user concept (see above). In most cases, you should only use the primary user id (user.id or session.getUserId()) if you are associating data to users. Still, in some cases you need to specifically refer to a login method, which is covered by the new RecipeUserId class:

• You can get it:
  • From a session by: session.getRecipeUserId().
  • By finding the appropriate entry in the loginMethods array of a User object (see above): user.loginMethods[0].recipeUserId.
• It wraps a simple string value that you can get by calling recipeUserId.getAsString().
• We've introduced it to differentiate between primary and recipe user ids in our APIs on a type level.
• Check here for more information.

Breaking changes

• Now only supporting CDI 4.0. Compatible with core version >= 7.0

• Now supporting FDI 1.18

• Removed the recipe specific User type, now all functions are using the new generic User type.

  • Check here for more information.

• The build function and the fetchValue callback of session claims now take a new recipeUserId param.

  • This affects built-in claims: EmailVerificationClaim, UserRoleClaim, PermissionClaim, AllowedDomainsClaim.
  • This will affect all custom claims as well built on our base classes.

• Now ignoring protected props in the payload in createNewSession and createNewSessionWithoutRequestResponse

• createdNewUser has been renamed to createdNewRecipeUser in sign up related APIs and functions

• EmailPassword:

  • removed getUserById, getUserByEmail. You should use supertokens.getUser, and supertokens. listUsersByAccountInfo instead
  • added consumePasswordResetToken. This function allows the consumption of the reset password token without changing the password. It will return OK if the token was valid.
  • added an overrideable createNewRecipeUser function that is called during sign up and password reset flow (in case a new email password user is being created on the fly). This is mostly for internal use.
  • recipeUserId is added to the input of getContent of the email delivery config
  • email was added to the input of createResetPasswordToken , sendResetPasswordEmail, createResetPasswordLink
  • updateEmailOrPassword :
    • now takes recipeUserId instead of userId
    • can return the new EMAIL_CHANGE_NOT_ALLOWED_ERROR status
  • signIn:
    • returns new recipeUserId prop in the status: OK case
  • signUp:
    • returns new recipeUserId prop in the status: OK case
  • resetPasswordUsingToken:
    • removed from the recipe interface, making it no longer overrideable (directly)
    • the related function in the index files now call consumePasswordResetToken and updateEmailOrPassword
    • any necessary behaviour changes can be achieved by overriding those two function instead
  • signInPOST:
    • can return status SIGN_IN_NOT_ALLOWED
  • signUpPOST:
    • can return status SIGN_UP_NOT_ALLOWED
  • generatePasswordResetTokenPOST:
    • can now return PASSWORD_RESET_NOT_ALLOWED
  • passwordResetPOST:
    • now returns the user and the email whose password was reset
    • can now return PASSWORD_POLICY_VIOLATED_ERROR

• EmailVerification:

  • createEmailVerificationToken, createEmailVerificationLink, isEmailVerified, revokeEmailVerificationTokens , unverifyEmail:
    • now takes recipeUserId instead of userId
  • sendEmailVerificationEmail :
    • now takes an additional recipeUserId parameter
  • verifyEmailUsingToken:
    • now takes a new attemptAccountLinking parameter
    • returns the recipeUserId instead of id
  • sendEmail now requires a new recipeUserId as part of the user info
  • getEmailForUserId config option was renamed to getEmailForRecipeUserId
  • verifyEmailPOST, generateEmailVerifyTokenPOST: returns an optional newSession in case the current user session needs to be updated

• Passwordless:

  • removed getUserById, getUserByEmail, getUserByPhoneNumber
  • updateUser :
    • now takes recipeUserId instead of userId
    • can return "EMAIL_CHANGE_NOT_ALLOWED_ERROR and PHONE_NUMBER_CHANGE_NOT_ALLOWED_ERROR statuses
  • createCodePOST and consumeCodePOST can now return SIGN_IN_UP_NOT_ALLOWED

• Session:

  • access tokens and session objects now contain the recipe user id
  • Support for new access token version
  • recipeUserId is now added to the payload of the TOKEN_THEFT_DETECTED error
  • createNewSession: now takes recipeUserId instead of userId
  • Removed validateClaimsInJWTPayload
  • revokeAllSessionsForUser now takes an optional revokeSessionsForLinkedAccounts param
  • getAllSessionHandlesForUser now takes an optional fetchSessionsForAllLinkedAccounts param
  • regenerateAccessToken return value now includes recipeUserId
  • getGlobalClaimValidators and validateClaims now get a new recipeUserId param
  • Added getRecipeUserId to the session class

• ThirdParty:

  • The signInUp override:
    • gets a new isVerified param
    • can return new status: SIGN_IN_UP_NOT_ALLOWED
  • manuallyCreateOrUpdateUser:
    • gets a new isVerified param
    • can return new statuses: EMAIL_CHANGE_NOT_ALLOWED_ERROR, SIGN_IN_UP_NOT_ALLOWED
  • Removed getUserByThirdPartyInfo, getUsersByEmail, getUserById
  • signInUpPOST can now return SIGN_IN_UP_NOT_ALLOWED

• ThirdPartyEmailPassword:

  • Removed getUserByThirdPartyInfo, getUsersByEmail, getUserById
  • thirdPartyManuallyCreateOrUpdateUser:
    • now get a new isVerified param
    • can return new statuses: EMAIL_CHANGE_NOT_ALLOWED_ERROR, SIGN_IN_UP_NOT_ALLOWED
  • The thirdPartySignInUp override:
    • now get a new isVerified param
    • can return new status: SIGN_IN_UP_NOT_ALLOWED
  • email was added to the input of createResetPasswordToken , sendResetPasswordEmail, createResetPasswordLink
  • added an overrideable createNewEmailPasswordRecipeUser function that is called during email password sign up and in the “invitation link” flow
  • added consumePasswordResetToken
  • updateEmailOrPassword :
    • now takes recipeUserId instead of userId
    • can return the new EMAIL_CHANGE_NOT_ALLOWED_ERROR status
  • resetPasswordUsingToken:
    • removed from the recipe interface, making it no longer overrideable (directly)
    • the related function in the index files now call consumePasswordResetToken and updateEmailOrPassword
    • any necessary behaviour changes can be achieved by overriding those two function instead
  • added an overrideable createNewEmailPasswordRecipeUser function that is called during sign up and in the “invitation link” flow
  • emailPasswordSignIn:
    • returns new recipeUserId prop in the status: OK case
  • emailPasswordSignUp:
    • returns new recipeUserId prop in the status: OK case
  • emailPasswordSignInPOST:
    • can return status SIGN_IN_NOT_ALLOWED
  • emailPasswordSignUpPOST:
    • can return status SIGN_UP_NOT_ALLOWED
  • generatePasswordResetTokenPOST:
    • can now return PASSWORD_RESET_NOT_ALLOWED
  • passwordResetPOST:
    • now returns the user and the email whose password was reset
    • can now return PASSWORD_POLICY_VIOLATED_ERROR
  • thirdPartySignInUpPOST can now return SIGN_IN_UP_NOT_ALLOWED

• ThirdPartyPasswordless:

  • Removed getUserByThirdPartyInfo, getUsersByEmail, getUserByPhoneNumber, getUserById
  • thirdPartyManuallyCreateOrUpdateUser:
    • gets a new isVerified param
    • can return new statuses: EMAIL_CHANGE_NOT_ALLOWED_ERROR, SIGN_IN_UP_NOT_ALLOWED
  • The thirdPartySignInUp override:
    • gets a new isVerified param
    • can return new status: SIGN_IN_UP_NOT_ALLOWED
  • updatePasswordlessUser:
    • now takes recipeUserId instead of userId
    • can return "EMAIL_CHANGE_NOT_ALLOWED_ERROR and PHONE_NUMBER_CHANGE_NOT_ALLOWED_ERROR statuses
  • thirdPartySignInUpPOST can now return SIGN_IN_UP_NOT_ALLOWED
  • createCodePOST and consumeCodePOST can now return SIGN_IN_UP_NOT_ALLOWED

• Multitenancy:

  • associateUserToTenant can now return ASSOCIATION_NOT_ALLOWED_ERROR
  • associateUserToTenant and disassociateUserFromTenant now take RecipeUserId instead of a string user id

Changes

• Added RecipeUserId and a generic User class
• Added getUser, listUsersByAccountInfo, convertToRecipeUserId to the main exports
• Updated compilation target of typescript to ES2017 to make debugging easier.
• Added account-linking recipe

Migration guide

New User structure

We've added a generic User class 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 (or user.loginMethods[0].recipeUserId in case you need RecipeUserId)
• 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

RecipeUserId

Some functions now require you to pass a RecipeUserId instead of a string user id. If you are using our auth recipes, you can find the recipeUserId as: user.loginMethods[0].recipeUserId (you'll need to worry about selecting the right login method after enabling account linking). Alternatively, if you already have a string user id you can convert it to a RecipeUserId using supertokens.convertToRecipeUserId(userIdString)

Checking if a user signed up or signed in

• In the 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;

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

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

Changing user emails

• We recommend that you check if the email change of a user is allowed, before calling the update function
  • Check here for more information

import {isEmailChangeAllowed} from "supertokens-node/recipe/accountlinking";
/// ...
app.post("/change-email", verifySession(), async (req: SessionRequest, res: express.Response) => {
    let session = req.session!;
    let email = req.body.email;

    // ...
    if (!(await isEmailChangeAllowed(session.getRecipeUserId(), email, false))) {
        // this can come here if you have enabled the account linking feature, and
        // if there is a security risk in changing this user's email.
    }

    // Update the email
    let resp = await ThirdPartyEmailPassword.updateEmailOrPassword({
        recipeUserId: session.getRecipeUserId(),
        email: email,
    });
    // ...
});

v15.2.3

Compare Source

What's Changed

• fix: thirdparty recursion and config reference issues by @​sattvikc in https://github.com/supertokens/supertokens-node/pull/847

Full Changelog: supertokens/supertokens-node@v15.2.2...v15.2.3

v15.2.2

Compare Source

What's Changed

• fix: backport to core 6.0 by @​sattvikc in https://github.com/supertokens/supertokens-node/pull/812
• fix: cicd by @​sattvikc in https://github.com/supertokens/supertokens-node/pull/814

Full Changelog: supertokens/supertokens-node@v17.0.2...v15.2.2

---

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.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

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

---

This PR has been generated by Mend Renovate. View repository job log here.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 416826d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

📚 Storybook Deployment

The latest changes are available as preview in: https://c4447b79.hive-storybook.pages.dev

[github-actions]

🐋 This PR was built and pushed to the following Docker images (tag: 3cbefa0ff06f05bfd5a89cffa0ab616079d463fe):

Docker Bake metadata

{
"app": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/kj6i3avlqi5gmqesn4mf7isj3",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:aa4024ebf56d0a9f7d8d6d29c68cbfaef73849f6fc30b9a0615c46408b7dcff2",
    "size": 685
  },
  "containerimage.digest": "sha256:aa4024ebf56d0a9f7d8d6d29c68cbfaef73849f6fc30b9a0615c46408b7dcff2",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/app:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/app:renovate_major_supertokens"
},
"composition-federation-2": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/opw9yifyvv1tdrewzur7jz9ak",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:56e2ae62cac27f0b15c1dc520b53c779f5601eb1098c96278aa049deebb1c5f9",
    "size": 685
  },
  "containerimage.digest": "sha256:56e2ae62cac27f0b15c1dc520b53c779f5601eb1098c96278aa049deebb1c5f9",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/composition-federation-2:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/composition-federation-2:renovate_major_supertokens"
},
"emails": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/t08rlp3c4l4f2ao0zelwuw3lp",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:376a81f5afc7455eb94750e5571ebe60025d79d7b5f39cc4d32c29a835b437b0",
    "size": 685
  },
  "containerimage.digest": "sha256:376a81f5afc7455eb94750e5571ebe60025d79d7b5f39cc4d32c29a835b437b0",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/emails:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/emails:renovate_major_supertokens"
},
"policy": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/emju0128rstm4vf7nbpjtlx8g",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:f7e3705cfe21bc1753796847670a95ba62458f0e2a68bef79d5b263b379b8231",
    "size": 685
  },
  "containerimage.digest": "sha256:f7e3705cfe21bc1753796847670a95ba62458f0e2a68bef79d5b263b379b8231",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/policy:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/policy:renovate_major_supertokens"
},
"rate-limit": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/mmv7flv9svywhrj2hn092gkrd",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:d3b613f78420882db2dd03c514f6a17af5df47b4d03985c422bd884cabea0791",
    "size": 685
  },
  "containerimage.digest": "sha256:d3b613f78420882db2dd03c514f6a17af5df47b4d03985c422bd884cabea0791",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/rate-limit:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/rate-limit:renovate_major_supertokens"
},
"schema": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/mils7xm10v7scdbzez41wztr2",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:5ff0ffee831360c6f76db2258245d77848118dcf117183b403179262f1fee22f",
    "size": 685
  },
  "containerimage.digest": "sha256:5ff0ffee831360c6f76db2258245d77848118dcf117183b403179262f1fee22f",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/schema:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/schema:renovate_major_supertokens"
},
"server": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/wfi7m4vfn1qpjl8p0ty6uubbx",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:a8854d3c5e49797949a5dbe5fe1cc0ecc6eaa57605d263e78820a66a607e9e0b",
    "size": 685
  },
  "containerimage.digest": "sha256:a8854d3c5e49797949a5dbe5fe1cc0ecc6eaa57605d263e78820a66a607e9e0b",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/server:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/server:renovate_major_supertokens"
},
"storage": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/xsccfhci7zx2l91dxd8yd1o2g",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:e6e1a56fb0407380db1ee6c7c0174173d7899d74da288b68ab5bac77428fb549",
    "size": 685
  },
  "containerimage.digest": "sha256:e6e1a56fb0407380db1ee6c7c0174173d7899d74da288b68ab5bac77428fb549",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/storage:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/storage:renovate_major_supertokens"
},
"stripe-billing": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/qiiy1zgv1204cz4al6lgb0xog",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:aa625b02158b98672e05dd40ea83a4fbf619a58868223274fabbad94fcc1890c",
    "size": 685
  },
  "containerimage.digest": "sha256:aa625b02158b98672e05dd40ea83a4fbf619a58868223274fabbad94fcc1890c",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/stripe-billing:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/stripe-billing:renovate_major_supertokens"
},
"tokens": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/x38z3yv7xy3cnkpbxu5hlj2lv",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:909e83eb8efb6d7e43042a9cd82f72b9e2c14f915c0ed80a07e005846002c629",
    "size": 685
  },
  "containerimage.digest": "sha256:909e83eb8efb6d7e43042a9cd82f72b9e2c14f915c0ed80a07e005846002c629",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/tokens:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/tokens:renovate_major_supertokens"
},
"usage": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/yiroaj9cvgpuxxfzks7gwc6pg",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:6a07966e319abfe62411699eb3ff46137a607304fdd16e7cece660cd2e87754d",
    "size": 685
  },
  "containerimage.digest": "sha256:6a07966e319abfe62411699eb3ff46137a607304fdd16e7cece660cd2e87754d",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/usage:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/usage:renovate_major_supertokens"
},
"usage-estimator": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/nigr0iy17ewh8nv79t0h18439",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:192693e4dcb1b7109ac41752fb2004b90bc0e29ce015085f788b817c3d0f71a3",
    "size": 685
  },
  "containerimage.digest": "sha256:192693e4dcb1b7109ac41752fb2004b90bc0e29ce015085f788b817c3d0f71a3",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/usage-estimator:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/usage-estimator:renovate_major_supertokens"
},
"usage-ingestor": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/1w8bq0fb2qadbh7wg8w7yvar2",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:07dcbd3bd51a104968f9c2cbb4a61a24e984cd2de347309118f236b28642c8b4",
    "size": 685
  },
  "containerimage.digest": "sha256:07dcbd3bd51a104968f9c2cbb4a61a24e984cd2de347309118f236b28642c8b4",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/usage-ingestor:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/usage-ingestor:renovate_major_supertokens"
},
"webhooks": {
  "buildx.build.ref": "builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f/builder-9d168160-ffc0-48cc-bfc3-7ab8517efd5f0/jr978n45agzjzenph8npdu31o",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "digest": "sha256:b1aa771d2cc8bfdd54df5d5edb7d00e13a0a208b990de69e11c5be682ac5d814",
    "size": 685
  },
  "containerimage.digest": "sha256:b1aa771d2cc8bfdd54df5d5edb7d00e13a0a208b990de69e11c5be682ac5d814",
  "image.name": "ghcr.io/kamilkisiela/graphql-hive/webhooks:3cbefa0ff06f05bfd5a89cffa0ab616079d463fe,ghcr.io/kamilkisiela/graphql-hive/webhooks:renovate_major_supertokens"
}
}

[github-actions]

🚀 Snapshot Release (alpha)

The latest changes of this PR are available as alpha on npm (based on the declared changesets):

Package	Version	Info
@graphql-hive/apollo	0.33.0-alpha-20240423160101-610b4bb1f3d3a40e9989facf05fa35e9db00b773	npm ↗︎ unpkg ↗︎
@graphql-hive/cli	0.37.0-alpha-20240423160101-610b4bb1f3d3a40e9989facf05fa35e9db00b773	npm ↗︎ unpkg ↗︎
@graphql-hive/core	0.3.0-alpha-20240423160101-610b4bb1f3d3a40e9989facf05fa35e9db00b773	npm ↗︎ unpkg ↗︎
@graphql-hive/envelop	0.33.0-alpha-20240423160101-610b4bb1f3d3a40e9989facf05fa35e9db00b773	npm ↗︎ unpkg ↗︎
@graphql-hive/yoga	0.33.0-alpha-20240423160101-610b4bb1f3d3a40e9989facf05fa35e9db00b773	npm ↗︎ unpkg ↗︎