Hello, we've updated from supertokens-auth-react v0.24.0 to v0.31.0 and supertokens-node from 11.0.0...

seren

02/13/2023, 5:38 PM

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.

rp_st

02/13/2023, 5:39 PM

hey @seren

rp_st

02/13/2023, 5:39 PM

@porcellus can help here

seren

02/13/2023, 5:39 PM

Thanks 🙂

porcellus

02/13/2023, 5:40 PM

porcellus

02/13/2023, 5:40 PM

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

seren

02/13/2023, 5:42 PM

Any info in particular are you looking for? We're using Fastify with the GitHub third party provider.

porcellus

02/13/2023, 5:46 PM

apiDomain

and

websiteDomain

different? are there session specific settings like:

cookieDomain

sessionTokenFrontendDomain

sessionTokenBackendDomain

seren

02/13/2023, 5:49 PM

apiDomain and websiteDomain are different. cookieDomain is set but sessionTokenFrontendDomain and sessionTokenBackendDomain aren't.

porcellus

02/13/2023, 5:54 PM

just double checking:

cookieDomain

has been renamed in the frontend settings to

sessionTokenBackendDomain

(similarly,

cookieScope

has been renamed to

sessionTokenFrontendDomain

)

seren

02/13/2023, 5:58 PM

We have cookieDomain set only in the backend for supertokens-node (and not in frontend settings).

seren

02/13/2023, 5:58 PM

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; }; ```

porcellus

02/13/2023, 5:59 PM

the backend still uses the same name, because that setting only affects the cookie based sessions.

rp_st

02/13/2023, 6:00 PM

if you had cookieDomain set previously, it probably means you want to share sessions across backend sub domains - is that correct?

rp_st

02/13/2023, 6:02 PM

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

rp_st

02/13/2023, 6:20 PM

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?

seren

02/13/2023, 6:22 PM

1. No 2. Refreshes

seren

02/13/2023, 6:23 PM

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

rp_st

02/13/2023, 6:29 PM

Do those users get stuck in an infinite refresh loop? Or do they get logged out, and then can't login?

seren

02/13/2023, 6:29 PM

Logged out and can't log in

rp_st

02/13/2023, 6:31 PM

Is it possible to get a screenshot of their cookie store post successful login attempt?

rp_st

02/13/2023, 6:33 PM

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?

Morgante Pell

02/13/2023, 6:38 PM

Cache is unlikely to be the issue, we don't have any aggressive caching set and asked them to do a full reload.

Morgante Pell

02/13/2023, 6:40 PM

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

porcellus

02/13/2023, 6:40 PM

oh, this is very useful 🙂

porcellus

02/13/2023, 6:41 PM

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

porcellus

02/13/2023, 6:42 PM

oh I think I misread something, sorry

rp_st

02/13/2023, 7:15 PM

Would it be possible to ask the user to provide a screenshot of their cookie store please?

Morgante Pell

02/13/2023, 7:23 PM

It’s tough to replicate unfortunately, so I don’t have a copy of the cookie store.

porcellus

02/13/2023, 8:30 PM

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.

porcellus

02/13/2023, 8:32 PM

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.

Morgante Pell

02/16/2023, 6:36 PM

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?

rp_st

02/17/2023, 12:17 AM

The cookie store on your browser, and the api calls being made due to infinite loop

rp_st

02/17/2023, 12:17 AM

And their request and response headers please

Morgante Pell

02/17/2023, 1:44 PM

DMing you.

rp_st

02/17/2023, 1:45 PM

rp_st

02/17/2023, 2:00 PM

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?

rp_st

02/17/2023, 2:03 PM

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?

rp_st

02/17/2023, 3:52 PM

hey @porcellus is free now for a call

rp_st

02/17/2023, 3:52 PM

are you free now @Morgante Pell ?

rp_st

02/17/2023, 4:08 PM

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

rp_st

02/17/2023, 4:09 PM

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

rp_st

02/17/2023, 4:16 PM

Also you can remove the sessionFrontendDomain and sessionBackendDomain setting

Morgante Pell

02/17/2023, 4:36 PM

Yes there is a 400 error from GraphQL but that error is the context creation failing - ie. the JWT can't be verified.

Morgante Pell

02/17/2023, 4:36 PM

Copy code

{
  "errors": [
    {
      "message": "Context creation failed: Error verifying token",
      "extensions": {
        "code": "AUTH_ERROR"
      }
    }
  ]
}

rp_st

02/17/2023, 4:42 PM

Right. So that’s the issue it seems

rp_st

02/17/2023, 4:42 PM

And that why you are getting logged out

rp_st

02/17/2023, 4:43 PM

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

Previous Next

SuperTokens.com

SuperTokens is an open source authentication solution offering features like: Different types of login: Email / password, Passwordless (OTP or Magic link based).