fix: duplicate session token issue when cookieDomain is changed

[anku255]

Summary of change

• Added olderCookieDomain config option in the session recipe. This will allow users to clear cookies from older domain when the cookieDomain is changed.
• Fixed an issue where the access token wasn't cleared if refresh token API was called without a refresh token

On changing cookieSameSite or cookieSecure config

Changing these values simply overwrites the existing cookies with updated values.

On request spike

If an authenticated API is called after cookie domain has changed and token has expired then it would call the authenticated API 3 times while refresh API 2 times to get back to the normal state. Here is a screenshot -

On decision to clear cookies from refresh api layer

Originally, we planned to remove duplicate cookies from all session functions, including getSession, createSession, and refreshSession. However, some JavaScript frameworks don't permit reading the response cookie header, preventing us from setting multiple cookies with the same name and removing duplicates effectively. This approach would have led to inconsistency. Therefore, we decided to clear cookies only from the refresh API endpoint.

There was also a discussion regarding clearing cookies from getSession / verifySession along with refresh endpoint API but since this would have led to inconsistent behaviour among different JS frameworks, we decided against it. The saving in API call wasn't worth the inconsistency.

Related issues

• https://github.com/supertokens/supertokens-node/issues/790
• https://github.com/supertokens/supertokens-node/issues/826

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)

Documentation changes

(If relevant, please create a PR in our docs repo, or create a checklist here highlighting the necessary changes)

Checklist for important updates

• [x] Changelog has been updated
• [ ] coreDriverInterfaceSupported.json file has been updated (if needed)
  • Along with the associated array in lib/ts/version.ts
• [ ] frontendDriverInterfaceSupported.json file has been updated (if needed)
• [x] Changes to the version if needed
  • In package.json
  • In package-lock.json
  • In lib/ts/version.ts
• [x] Had run npm run build-pretty
• [x] Had installed and ran the pre-commit hook
• [ ] If new thirdparty provider is added,
  • [ ] update switch statement in recipe/thirdparty/providers/configUtils.ts file, createProvider function.
  • [ ] add an icon on the user management dashboard.
• [x] Issue this PR against the latest non released version branch.
  • To know which one it is, run find the latest released tag (git tag) in the format vX.Y.Z, and then find the latest branch (git branch --all) whose X.Y is greater than the latest released tag.
  • If no such branch exists, then create one from the latest released branch.
• [ ] If have added a new web framework, update the add-ts-no-check.js file to include that
• [ ] If added a new recipe / api interface, then make sure that the implementation of it uses NON arrow functions only (like someFunc: function () {..}).
• [ ] If added a new recipe, then make sure to expose it inside the recipe folder present in the root of this repo. We also need to expose its types.

---

	:rocket: This PR description was created by Ellipsis for commit 771782a80c44697e8e43d354e3547382dead7e50.

Summary:

This PR adds a new olderCookieDomain config option to handle cases where the cookieDomain is changed and fixes an issue where the access token wasn't cleared if the refresh token API was called without a refresh token.

Key points:

• Added olderCookieDomain config option in the session recipe to handle cases where the cookieDomain is changed.
• Fixed an issue where the access token wasn't cleared if the refresh token API was called without a refresh token.
• Updated session API implementation, cookie and header handling, and session request functions to accommodate the new changes.
• Added tests to verify the new behavior.

---

Generated with :heart: by ellipsis.dev

[rishabhpoddar]

Different cases to consider:

Case 1

• apiDomain: api.example.com
• User sets cookieDomain to "api.example.com" (used to be < not set >)
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 2

• apiDomain: api.example.com
• User sets cookieDomain to ".example.com" (used to be < not set >)
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 3

• apiDomain: api.example.com
• User changes cookieDomain from "api.example.com" to < not set >
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 4

• apiDomain: api.example.com
• User changes cookieDomain from ".example.com" to < not set >
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 5

• apiDomain: api.example.com
• User changes cookieDomain from "api.example.com" to ".example.com
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 6

• apiDomain: api.example.com
• User changes cookieDomain from ".example.com" to "api.example.com
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 7

• apiDomain changed from example.com to api.example.com
• User changes cookieDomain from ".example.com" to < not set >
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 8

• apiDomain changed from example.com to api.example.com
• User changes cookieDomain from ".example.com" to "api.example.com"
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 9

• apiDomain changed from example.com to api.example.com
• User changes cookieDomain from "example.com" to "api.example.com"
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 10

• apiDomain changed from example.com to api.example.com
• User changes cookieDomain from to "api.example.com"
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 11

• apiDomain changed from example.com to api.example.com
• User changes cookieDomain from to ".example.com"
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 12

• apiDomain changed from api.example.com to example.com
• User changes cookieDomain from ".example.com" to < not set >
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 13

• apiDomain changed from api.example.com to example.com
• User changes cookieDomain from ".example.com" to "example.com"
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 14

• apiDomain changed from api.example.com to example.com
• User changes cookieDomain from "api.example.com" to "example.com"
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 15

• apiDomain changed from api.example.com to example.com
• User changes cookieDomain from < not set > to "example.com"
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

Case 16

• apiDomain changed from api.example.com to example.com
• User changes cookieDomain from < not set >to ".example.com"
• Value of olderCookieDomain: TODO

Behaviour of API call:

• CreateNewSession: TODO
• GetSession / VerifySession: TODO
• RefreshSession: TODO

[anku255]

I tested all the cases and the behavior is quite uniform for all of them.

The gist is that the olderCookieDomain needs to be exactly same as the older cookie domain or "" if it wasn't set.

Once the cookie domain is changed, we will end up setting session cookies with the newer cookie domain while the older ones will be removed only after refresh endpoint is called. The refresh endpoint will be called the moment we get a 401 and this would happen once the older tokens expire.

All the cases are listed below:

Case 1

• apiDomain: api.example.com
• User sets cookieDomain to "api.example.com" (used to be < not set >)
• Value of olderCookieDomain: ""

Behaviour of API call:

• CreateNewSession:
  • It will create a new session with api.example.com cookie domain.
• GetSession / VerifySession:
  • If the older access token was valid then it will return the session information.
  • If the older access token was invalid then it will return a 401, leading to refresh api call.
    • The first refresh call will set new cookies with api.example.com cookie domain.
    • The GetSession endpoint will be called again, it will again return 401 because older cookies were used to verify session.
    • The second refresh call will remove the older cookies and return a 200.
    • The GetSession endpoint will be called again, this time the session information will be returned correctly.
• RefreshSession:
  • The first refresh call will set new cookies with api.example.com cookie domain.
  • The second refresh call will remove the older cookies and return a 200.

Case 2

• apiDomain: api.example.com
• User sets cookieDomain to ".example.com" (used to be < not set >)
• Value of olderCookieDomain: ""

Behaviour of API call:

• CreateNewSession:
  • It will create a new session with .example.com cookie domain.
• GetSession / VerifySession:
  • If the older access token was valid then it will return the session information.
  • If the older access token was invalid then it will return a 401, leading to refresh api call.
    • The first refresh call will set new cookies with .example.com cookie domain.
    • The GetSession endpoint will be called again, it will again return 401 because older cookies were used to verify session.
    • The second refresh call will remove the older cookies and return a 200.
    • The GetSession endpoint will be called again, this time the session information will be returned correctly.
• RefreshSession:
  • The first refresh call will set new cookies with .example.com cookie domain.
  • The second refresh call will remove the older cookies and return a 200.

Case 3

• apiDomain: api.example.com
• User changes cookieDomain from "api.example.com" to < not set >
• Value of olderCookieDomain: "api.example.com"

Behaviour of API call:

• CreateNewSession:
  • It will create a new session with "" cookie domain. The browser may show it as "api.example.com" cookie domain.
• GetSession / VerifySession:
  • If the older access token was valid then it will return the session information.
  • If the older access token was invalid then it will return a 401, leading to refresh api call.
    • The first refresh call will set new cookies with "" cookie domain.
    • The GetSession endpoint will be called again, it will again return 401 because older cookies were used to verify session.
    • The second refresh call will remove the older cookies and return a 200.
    • The GetSession endpoint will be called again, this time the session information will be returned correctly.
• RefreshSession:
  • The first refresh call will set new cookies with "" cookie domain.
  • The second refresh call will remove the older cookies and return a 200.

Case 4

• apiDomain: api.example.com
• User changes cookieDomain from ".example.com" to < not set >
• Value of olderCookieDomain: ".example.com"

Behaviour of API call:

• CreateNewSession:
  • It will create a new session with "" cookie domain. The browser may show it as "api.example.com" cookie domain.
• GetSession / VerifySession:
  • If the older access token was valid then it will return the session information.
  • If the older access token was invalid then it will return a 401, leading to refresh api call.
    • The first refresh call will set new cookies with "" cookie domain.
    • The GetSession endpoint will be called again, it will again return 401 because older cookies were used to verify session.
    • The second refresh call will remove the older cookies and return a 200.
    • The GetSession endpoint will be called again, this time the session information will be returned correctly.
• RefreshSession:
  • The first refresh call will set new cookies with "" cookie domain.
  • The second refresh call will remove the older cookies and return a 200

Case 5

• apiDomain: api.example.com
• User changes cookieDomain from "api.example.com" to ".example.com
• Value of olderCookieDomain: "api.example.com"

Behaviour of API call:

• CreateNewSession:
  • It will create a new session with .example.com cookie domain.
• GetSession / VerifySession:
  • If the older access token was valid then it will return the session information.
  • If the older access token was invalid then it will return a 401, leading to refresh api call.
    • The first refresh call will set new cookies with .example.com cookie domain.
    • The GetSession endpoint will be called again, it will again return 401 because older cookies were used to verify session.
    • The second refresh call will remove the older cookies and return a 200.
    • The GetSession endpoint will be called again, this time the session information will be returned correctly.
• RefreshSession:
  • The first refresh call will set new cookies with .example.com cookie domain.
  • The second refresh call will remove the older cookies and return a 200.

Case 6

• apiDomain: api.example.com
• User changes cookieDomain from ".example.com" to "api.example.com
• Value of olderCookieDomain: ".example.com"

Behaviour of API call:

• CreateNewSession:
  • It will create a new session with api.example.com cookie domain.
• GetSession / VerifySession:
  • If the older access token was valid then it will return the session information.
  • If the older access token was invalid then it will return a 401, leading to refresh api call.
    • The first refresh call will set new cookies with api.example.com cookie domain.
    • The GetSession endpoint will be called again, it will again return 401 because older cookies were used to verify session.
    • The second refresh call will remove the older cookies and return a 200.
    • The GetSession endpoint will be called again, this time the session information will be returned correctly.
• RefreshSession:
  • The first refresh call will set new cookies with api.example.com cookie domain.
  • The second refresh call will remove the older cookies and return a 200.

Case 7

• apiDomain changed from example.com to api.example.com
• User changes cookieDomain from ".example.com" to < not set >
• Value of olderCookieDomain: ".example.com"

Behaviour of API call:

• CreateNewSession:
  • It will create a new session with "" cookie domain. The browser may show it as "api.example.com" cookie domain.
• GetSession / VerifySession:
  • If the older access token was valid then it will return the session information.
  • If the older access token was invalid then it will return a 401, leading to refresh api call.
    • The first refresh call will set new cookies with "" cookie domain.
    • The GetSession endpoint will be called again, it will again return 401 because older cookies were used to verify session.
    • The second refresh call will remove the older cookies and return a 200.
    • The GetSession endpoint will be called again, this time the session information will be returned correctly.
• RefreshSession:
  • The first refresh call will set new cookies with "" cookie domain.
  • The second refresh call will remove the older cookies and return a 200

Case 8

• apiDomain changed from example.com to api.example.com
• User changes cookieDomain from ".example.com" to "api.example.com"
• Value of olderCookieDomain: ".example.com"

Behaviour of API call:

• CreateNewSession:
  • It will create a new session with api.example.com cookie domain.
• GetSession / VerifySession:
  • If the older access token was valid then it will return the session information.
  • If the older access token was invalid then it will return a 401, leading to refresh api call.
    • The first refresh call will set new cookies with api.example.com cookie domain.
    • The GetSession endpoint will be called again, it will again return 401 because older cookies were used to verify session.
    • The second refresh call will remove the older cookies and return a 200.
    • The GetSession endpoint will be called again, this time the session information will be returned correctly.
• RefreshSession:
  • The first refresh call will set new cookies with api.example.com cookie domain.
  • The second refresh call will remove the older cookies and return a 200.

Case 9

• apiDomain changed from example.com to api.example.com
• User changes cookieDomain from "example.com" to "api.example.com"
• Value of olderCookieDomain: "example.com"

Behaviour of API call:

• CreateNewSession:
  • It will create a new session with api.example.com cookie domain.
• GetSession / VerifySession:
  • If the older access token was valid then it will return the session information.z`
  • If the older access token was invalid then it will return a 401, leading to refresh api call.
    • The first refresh call will set new cookies with api.example.com cookie domain.
    • The GetSession endpoint will be called again, it will again return 401 because older cookies were used to verify session.
    • The second refresh call will remove the older cookies and return a 200.
    • The GetSession endpoint will be called again, this time the session information will be returned correctly.
• RefreshSession:
  • The first refresh call will set new cookies with api.example.com cookie domain.
  • The second refresh call will remove the older cookies and return a 200.

Case 10

• apiDomain changed from example.com to api.example.com
• User changes cookieDomain from to "api.example.com"
• Value of olderCookieDomain: ""

Behaviour of API call:

The cookies set by example.com with cookieDomain < not set > won't be sent to the request when the domain changes to api.example.com but it would be stored in the browser until it expires. The user would get logged out and after sign in, all the APIs would behave as they do normally.

Case 11

• apiDomain changed from example.com to api.example.com
• User changes cookieDomain from < not set > to ".example.com"
• Value of olderCookieDomain: ""

Behaviour of API call:

The cookies set by example.com with cookieDomain < not set > won't be sent to the request when the domain changes to api.example.com but it would be stored in the browser until it expires. The user would get logged out and after sign in, all the APIs would behave as they do normally.

Case 12

• apiDomain changed from api.example.com to example.com
• User changes cookieDomain from ".example.com" to < not set >
• Value of olderCookieDomain: ".example.com"

Behaviour of API call:

• CreateNewSession:
  • It will create a new session with "" cookie domain. The browser may show it as "example.com" cookie domain.
• GetSession / VerifySession:
  • If the older access token was valid then it will return the session information.
  • If the older access token was invalid then it will return a 401, leading to refresh api call.
    • The first refresh call will set new cookies with "" cookie domain.
    • The GetSession endpoint will be called again, it will again return 401 because older cookies were used to verify session.
    • The second refresh call will remove the older cookies and return a 200.
    • The GetSession endpoint will be called again, this time the session information will be returned correctly.
• RefreshSession:
  • The first refresh call will set new cookies with "" cookie domain.
  • The second refresh call will remove the older cookies and return a 200.

Case 13

• apiDomain changed from api.example.com to example.com
• User changes cookieDomain from ".example.com" to "example.com"
• Value of olderCookieDomain: No need to set it but setting it to ".example.com" won't do any harm either.

Behaviour of API call:

The cookie domain change from .example.com to example.com wouldn't have any effect. The older cookies will get replaced by new ones as they would normally.

Case 14

• apiDomain changed from api.example.com to example.com
• User changes cookieDomain from "api.example.com" to "example.com"
• Value of olderCookieDomain: No need to set it but setting it to "api.example.com" won't do any harm either.

Behaviour of API call:

The cookies set by api.example.com with cookieDomain "api.example.com" won't be sent to the request when the domain changes to example.com but it would be stored in the browser until it expires. The user would get logged out and after sign in, all the APIs would behave as they do normally.

Case 15

• apiDomain changed from api.example.com to example.com
• User changes cookieDomain from < not set > to "example.com"
• Value of olderCookieDomain: No need to set it but setting it to "" won't do any harm either.

Behaviour of API call:

The cookies set by api.example.com with cookieDomain < not set > won't be sent to the request when the domain changes to example.com but it would be stored in the browser until it expires. The user would get logged out and after sign in, all the APIs would behave as they do normally.

Case 16

• apiDomain changed from api.example.com to example.com
• User changes cookieDomain from < not set > to ".example.com"
• Value of olderCookieDomain: No need to set it but setting it to "" won't do any harm either.

Behaviour of API call:

The cookies set by api.example.com with cookieDomain < not set > won't be sent to the request when the domain changes to example.com but it would be stored in the browser until it expires. The user would get logged out and after sign in, all the APIs would behave as they do normally.

[rishabhpoddar]

Hey @ellipsis, give me a code reivew

[ellipsis-dev[bot]]

OK! Reviewing this PR...

---

Responding to this comment by @rishabhpoddar. For more information about Ellipsis, check the documentation.

[porcellus]

Please explore/define the behaviors if:

• The api used to run on api.example.com
• Now they are introducing api2.example.com
• This should use/get the same session, so they update the cookieDomain unset to .example.com
• Plus setting their olderCookieDomain to "" (as I think that'd be the right thing to do. With this setup consider:
• The user has an active session with cookies set to api.example.com, that is valid for a long time
• They make a call to api2.example.com: they get a 401, so a refresh is called on api.example.com
• This sets up the new cookies with the new cookieDomain What happens then to requests made to api.example.com? Can this cause any issues? (Token theft detection is not triggered, however other strange things could happen)

[porcellus]

Please consider what happens if the user calls mergeIntoAccessTokenPayload (or tries to verify their email) in a case similar to Case 5 above.

[anku255]

@porcellus Thanks for coming up with these cases.

After testing these cases, I have found two breaking cases:

1. After the cookieDomain change, the updated token payload value won't be used until the older token expires. If the token payload doesn't change then its not an issue but if something like mergeIntoAccessTokenPayload is called then the updated value won't be used until the older token expires (and ultimately gets cleared by refresh call).

2. If there are > 1 session cookies and the olderCookieDomain is set, we will clear the cookies for the older domain and return 200. If the olderCookieDomain is incorrect then it will cause an infinite loop. This can only be fixed by setting olderCookieDomain to the correct value.

NOTE:

I tested the case with multiple API domains. There are no additional issue with this setup. The issue arises when api2.example.com updates the token payload. api.example.com will still use the old token payload until the token expires while api2.example.com will use the updated token payload.

[ellipsis-dev[bot]]

:warning: This PR is too large for Ellipsis, but support for larger PRs is coming soon.

---

Generated with :heart: by ellipsis.dev

[ellipsis-dev[bot]]

Sorry, Ellipsis encountered a problem while reviewing this PR at commit 6482c7e28a4f540a19bed7dbe2b00b895369dd09. Our team has been alerted and is investigating. (wflow_A6zrl1XD5puDh9rY) :robot: