https://supertokens.com/ logo
Join Discord
Powered by
Hello, we've updated from supertokens-auth-react v...
# support-questions-legacy
s
Hello, we've updated from supertokens-auth-react v0.24.0 to v0.31.0 and supertokens-node from 11.0.0 to 13.0.1 and switched from cookie to header-based tokens at the same time. We subsequently observed a few issues with users who had the old cookies not being able to log in until clearing the old cookies. Can anyone help on whether this is a known issue and how we can mitigate it? Thanks.
r
hey @seren
@porcellus can help here
s
Thanks 🙂
p
hi
can you tell me a bit more about your setup? the frontend and backend configs for supertokens would be useful
s
Any info in particular are you looking for? We're using Fastify with the GitHub third party provider.
p
is 
apiDomain
and 
websiteDomain
different? are there session specific settings like: 
cookieDomain
, 
sessionTokenFrontendDomain
, 
sessionTokenBackendDomain
?
s
apiDomain and websiteDomain are different. cookieDomain is set but sessionTokenFrontendDomain and sessionTokenBackendDomain aren't.
p
just double checking: 
cookieDomain
has been renamed in the frontend settings to 
sessionTokenBackendDomain
(similarly, 
cookieScope
has been renamed to 
sessionTokenFrontendDomain
)
s
We have cookieDomain set only in the backend for supertokens-node (and not in frontend settings).
Seems like the type for that config still uses
Copy code
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; }; ```
p
the backend still uses the same name, because that setting only affects the cookie based sessions.
r
if you had cookieDomain set previously, it probably means you want to share sessions across backend sub domains - is that correct?
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?
s
1. No 2. Refreshes
3. Not everyone, I haven't been able to reproduce myself. They use Chrome. 4. No
r
Do those users get stuck in an infinite refresh loop? Or do they get logged out, and then can't login?
s
Logged out and can't log in
r
Is it possible to get a screenshot of their cookie store post successful login attempt?
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?
m
Cache is unlikely to be the issue, we don't have any aggressive caching set and asked them to do a full reload.
Here's an example of some of the errors we saw on an invalid/failed state:
p
oh, this is very useful 🙂
so there seems to be a cors issue for the refresh endpoint
oh I think I misread something, sorry
r
Would it be possible to ask the user to provide a screenshot of their cookie store please?
m
It’s tough to replicate unfortunately, so I don’t have a copy of the cookie store.
p
How much of your userbase is affected? I'm trying to gauge how common the problem has to be. Also, There is a "A client side exception has occurred" line in the longs, I wonder what that could be.
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.
m
Ok so I am now personally impacted. I have an infinite loop and can't log in. I'm intentionally not clearing my cookies so we can try to debug - what info can I share?
r
The cookie store on your browser, and the api calls being made due to infinite loop
And their request and response headers please
m
DMing you.
r
ok
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 @Morgante Pell ?
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
m
Yes there is a 400 error from GraphQL but that error is the context creation failing - ie. the JWT can't be verified.
Copy code
{
  "errors": [
    {
      "message": "Context creation failed: Error verifying token",
      "extensions": {
        "code": "AUTH_ERROR"
      }
    }
  ]
}
r
Right. So that’s the issue it seems
And that why you are getting logged out
How are you fetching the JWT on the frontend and setting it in the request?
3 Views
PreviousNext
Powered by