@porcellus can help here

can you tell me a bit more about your setup? the frontend and backend configs for supertokens would be useful

Seems like the type for that config still uses

cookieDomain```:

export declare type TypeInput = { sessionExpiredStatusCode?: number; invalidClaimStatusCode?: number; cookieSecure?: boolean; cookieSameSite?: "strict" | "lax" | "none"; cookieDomain?: string; getTokenTransferMethod?: (input: { req: BaseRequest; forCreateNewSession: boolean; userContext: any; }) => TokenTransferMethod | "any"; errorHandlers?: ErrorHandlers; antiCsrf?: "VIA_TOKEN" | "VIA_CUSTOM_HEADER" | "NONE"; jwt?: | { enable: true; propertyNameInAccessTokenPayload?: string; issuer?: string; } | { enable: false; }; ```

if this is correct (i.e. you want to share sessions across backend sub domains), then you need to set the frontend's

sessionTokenBackendDomain

to the same value as the cookieDomain

Here are a few more questions: - Also, are you setting credentials: include manually when calling APIs from the frontend? - What is the observed behaviour - do session refreshes fail? Or does session verification fail? - Does this affect all your users or just a few of them? Anything unique about those users that are affected - for example do they use Safari or Brave browser etc.. - Did you change or add the cookieDomain config on the backend after the upgrade to the SDKs?

3. Not everyone, I haven't been able to reproduce myself. They use Chrome. 4. No

Is it possible that these users are using a cached version of the website that uses the older frontend SDK? Maybe purge your cache and ask them to reload?

Here's an example of some of the errors we saw on an invalid/failed state:

so there seems to be a cors issue for the refresh endpoint

oh I think I misread something, sorry

I'll try and debug this in the coming days, but unfortunately there is not much to go on; any more info would be appreciated.

And their request and response headers please

I see from the network cookies that

sIRTFrontend

is still set to

remove

- is that correct? Do you see that in your cookie store? If yes, were you using the frontend's sessionScope value before? And since that variable has been renamed, are you using

sessionTokenFrontendDomain

anymore?

Finally, you mentioned that "I have an infinite loop and can't log in." -> i do not see an infinite loop in the network tab - is there something else that's happening?

hey @porcellus is free now for a call

are you free now @veritas ?

so looking at the har file: 1. they call signinup, 2. call graphql, which returns a 400 3. I think they get redirected to auth/logout 4. Which calls our signout endpoint. this gets the appropriate response, so I think the session verification is working there. 5. they get redirected to login

So you might want to see why the frontend is redirected to the logout page. Is it cause of 400 response?

Also you can remove the sessionFrontendDomain and sessionBackendDomain setting

And that why you are getting logged out

How are you fetching the JWT on the frontend and setting it in the request?