[17.1.0] - 2024-04-25

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

[17.0.7] - 2024-05-03

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

[17.0.6] - 2024-05-02

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

[17.0.5] - 2024-04-25

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

[17.0.4] - 2024-04-09

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.

[17.0.3] - 2024-04-08

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

[17.0.2] - 2024-03-20

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

[17.0.1] - 2024-03-08

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.