Hey guys, we have implemented supertokens in our app and using COOKIE as Token transfer method. But...

dlighten08

04/25/2023, 2:07 PM

Hey guys, we have implemented supertokens in our app and using COOKIE as Token transfer method. But every time we try to login it's stuck in infinite refresh calls. Can anyone help!?

daledigital

04/25/2023, 10:33 PM

This happened to me today... I'm calling

Session.attemptingRefreshingSession()

from the browser (supertokens-web-js package) which fails to find the access token in the cookie. As far as I can tell, it looks like the cause is the API not being able to find the

sAccessToken

cookie, which isn't part of the request as it is

httpOnly

dlighten08

04/26/2023, 4:49 AM

It's happening while we try to login. So at the time there won't be anything cookies. And as result of infinite refresh calls the main signin api which sets the cookies, is not being called at all. Because supertokens check whether any existing tokens are there or not before signin/signup

rp_st

04/26/2023, 5:22 AM

hey @dlighten08 can you show us the following: - The backend debug logs when the refresh API is called. - The backend debug logs when the API that returns

is called. - The sign in response headers (Screenshot from chrome's network tab)

rp_st

04/26/2023, 5:22 AM

Also @daledigital - you shouldn't need to call

Session.attemptingRefreshingSession()

manually. Our network interceptors on the frontend should do auto refreshing - is that not happening?

dlighten08

04/26/2023, 5:31 AM

Hey @rp_st here is the network logs where we are getting the response as 200 and the initiator. also the point is none of the APIs are being called which returns 401. and sign is api it self is not being called due to this infinite. you can check the initiator of the first refresh call )

https://cdn.discordapp.com/attachments/1100422802256969788/1100655294759043153/Screenshot_2023-04-26_at_10.57.00_AM.png▾

https://cdn.discordapp.com/attachments/1100422802256969788/1100655294985539584/Screenshot_2023-04-26_at_10.57.29_AM.png▾

https://cdn.discordapp.com/attachments/1100422802256969788/1100655295233019934/Screenshot_2023-04-26_at_10.59.04_AM.png▾

dlighten08

04/26/2023, 5:32 AM

This is the backend log for the infinite refresh.

https://cdn.discordapp.com/attachments/1100422802256969788/1100655504931434526/Screenshot_2023-04-26_at_11.01.36_AM.png▾

rp_st

04/26/2023, 5:32 AM

can you enable backend debug log and show the output please?

dlighten08

04/26/2023, 5:40 AM

sure give a min

dlighten08

04/26/2023, 5:46 AM

here are the logs from debug. FYI: we are using super-token-web-js version 0.5.0 as FE SDK. https://cdn.discordapp.com/attachments/1100422802256969788/1100659049609039902/message.txt

rp_st

04/26/2023, 5:47 AM

Right. This might be an issye with the backend integration you have done with our SDK. Our SDK correctly says that it should return an

UNAUTHORISED

error, but the golang server is still returning a

. Have you followed our guides properly? Seen the golang example apps: https://github.com/supertokens/supertokens-golang/tree/master/examples

dlighten08

04/26/2023, 5:49 AM

also with every refresh it's updating the browser-tabs-lock-key-refresh_token_use in localstorage.

rp_st

04/26/2023, 5:49 AM

that's expected.

rp_st

04/26/2023, 5:49 AM

the issue is mostly on your backend - how you have integrated our middleware probably.

mayankgopronto

04/26/2023, 5:57 AM

https://cdn.discordapp.com/attachments/1100422802256969788/1100662030962274324/message.txt

mayankgopronto

04/26/2023, 5:58 AM

Copy code

r := chi.NewRouter()
    r.Use(cors.Handler(cors.Options{
        AllowedOrigins:   append([]string{ar.cfg.WebsiteDomain}, ar.cfg.CORSDomains...),
        AllowedMethods:   []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
        AllowedHeaders:   append([]string{"Content-Type"}, supertokens.GetAllCORSHeaders()...),
        AllowCredentials: true,
    }))

    r.Use(supertokens.Middleware)

    r.Get("/session-info", session.VerifySession(nil, ar.GetSessionInfo))

mayankgopronto

04/26/2023, 5:59 AM

But this backend works fine with the demo front end app. Which makes me believe the backend is fine. The refresh issue happens intermittently, some users are still able to log in.

rp_st

04/26/2023, 7:21 AM

are you, @mayankgopronto and @dlighten08 working on the same project? Im confused.

dlighten08

04/26/2023, 7:21 AM

Yes

rp_st

04/26/2023, 7:23 AM

right. Refresh sending a 200 when no token is passed to it is definitety a backend issue

rp_st

04/26/2023, 7:23 AM

what happens if you call the refresh API from postman without any refresh token?

rp_st

04/26/2023, 7:24 AM

Do you get back a 200 status code or a 401?

mayankgopronto

04/26/2023, 8:03 AM

So figured out the problem. It was a backend issue, in the

supertokens.Init()

I had passed custom

ErrorHandlers

. But I hadn't set

OnUnauthorised()

override. Thats why it returned

as the default. Thanks, fun debugging excercise anyway. 🙂

rp_st

04/26/2023, 8:08 AM

right! cool

daledigital

04/26/2023, 8:25 AM

Feel free to start a new thread for this (I don't know how) as it seems unrelated to this topic from the others. I was following the guide here: https://supertokens.com/docs/thirdparty/common-customizations/sessions/ssr I'm attempting to protect a route on the server-side by checking the session, then redirecting to the client-side route:

/auth/refresh-session

when

TRY_REFRESH_TOKEN

UNAUTHORISED

is returned by the server-side

SessionNode.getSession

rp_st

04/26/2023, 8:29 AM

ahh ok. In this case, you do need to call

attemptingRefreshingSession

. But is that not working?

daledigital

04/26/2023, 8:42 AM

Sorry,

SessionWeb.attemptRefreshingSession

works correctly as far as I can see. It successfully finds the refresh token in the cookie then attaches the refreshed session as a cookie in its response. The problem appears to be in the invocation of

SessionNode.getSession

. This always results in

UNAUTHORISED

after executing milliseconds after the client-side refresh.

daledigital

04/26/2023, 8:42 AM

Upon receiving

UNAUTHORISED

, I redirect back to the client-side refresh route and that creates the loop.

rp_st

04/26/2023, 8:55 AM

can you enabled backend debug logs and show me the output for when

SessionNode.getSession

returns

UNAUTHORISED

(after client refresh)

daledigital

04/26/2023, 8:57 AM

https://cdn.discordapp.com/attachments/1100422802256969788/1100707161069342730/message.txt

daledigital

04/26/2023, 8:58 AM

The first log is when I visit the protected route (called to

SessionNode.getSession

)

rp_st

04/26/2023, 8:59 AM

and then after the

Sending response to client with status code: 200

, there are no more logs from

getSession

daledigital

04/26/2023, 9:00 AM

I changed the redirect to prevent the loop - I'll post a one-iteration loop set of logs

daledigital

04/26/2023, 9:02 AM

https://cdn.discordapp.com/attachments/1100422802256969788/1100708363362369587/message.txt

rp_st

04/26/2023, 9:03 AM

So whats the api domain and website domain values in appinfo?

daledigital

04/26/2023, 9:04 AM

Copy code

appInfo: {
    appName: "My Site",
    apiDomain: process.env.VERCEL_URL ?? "http://localhost:5173",
    websiteDomain: process.env.VERCEL_URL ?? "http://localhost:5173",
  },

daledigital

04/26/2023, 9:08 AM

I'm using QwikJS btw. I am using API routes so my middleware is hosted on

http://localhost:5173/auth/[...]

and the client-side session handling is also there:

http://localhost:5173/auth/callback/linkedin

and

http://localhost:5173/auth/refresh-session

rp_st

04/26/2023, 9:11 AM

this appInfo should not work cause both the websiteDomain and the apiDomain are the same & the websiteBasePath and the apiBasePath are the same

rp_st

04/26/2023, 9:12 AM

so you might wanna add apiBasePath:

/api/auth

or something

daledigital

04/26/2023, 9:12 AM

Hmm, why must the base paths be different?

rp_st

04/26/2023, 9:13 AM

cause otherwise if you hit

http://localhost:5173/auth/...

should our middleware handle it? Or should the webserver route?

rp_st

04/26/2023, 9:14 AM

anyway, this is a different issue. for the SSR thing, can i see the request header for the request thats made by the browser when you navigate to the protected page?

daledigital

04/26/2023, 9:19 AM

https://cdn.discordapp.com/attachments/1100422802256969788/1100712683986239610/image.png▾

rp_st

04/26/2023, 9:21 AM

and can i see the refresh API call request and response? A full screenshot

daledigital

04/26/2023, 9:22 AM

I'm not sure what you mean

rp_st

04/26/2023, 9:22 AM

so when the refresh call is made to the backend, it's a network request - so it will shown up on the network tab

rp_st

04/26/2023, 9:23 AM

so what are the reqeust / response headers from that?

daledigital

04/26/2023, 9:23 AM

Ohh

daledigital

04/26/2023, 9:24 AM

https://cdn.discordapp.com/attachments/1100422802256969788/1100714076469993512/image.png▾

rp_st

04/26/2023, 9:26 AM

thats odd. the response header has no sAccessToken cookie being set?

rp_st

04/26/2023, 9:26 AM

or am i just not being able to see in the screenshot?

daledigital

04/26/2023, 9:27 AM

Yeah, seems that way:

https://cdn.discordapp.com/attachments/1100422802256969788/1100714883315679262/image.png▾

rp_st

04/26/2023, 9:28 AM

no i mean in the response from the refresh API cll

rp_st

04/26/2023, 9:28 AM

is there no sAccessToken cookie?

daledigital

04/26/2023, 9:29 AM

Yeah, that screenshot shows the Response Cookies which only has the refresh token

daledigital

04/26/2023, 9:29 AM

But isn't just using the current access token okay?

rp_st

04/26/2023, 9:30 AM

no.. it should set the access token as well.. are you doing something on the backend via overrides? Or handling sending the response on your own?

rp_st

04/26/2023, 9:30 AM

which versions of the forntend / backend SDk are you using?

daledigital

04/26/2023, 9:34 AM

Yeah, I'm doing something weird with the middleware handler because QwikJS's

req

and

res

are not compatible with ExpressJS

req

and

res

- I've (horribly) built custom request and response objects to pass to the middleware. Quite possible that the cookie setter has a bug....

https://cdn.discordapp.com/attachments/1100422802256969788/1100716522642608188/image.png▾

daledigital

04/26/2023, 9:34 AM

That's my

/auth/[...]

endpoint handler

rp_st

04/26/2023, 9:35 AM

right. So that may be why things arent working

rp_st

04/26/2023, 9:35 AM

you need to make sure that your custom req / res is able to set cookies properly

daledigital

04/26/2023, 9:36 AM

Okay, so I should expect

sAccessToken

to be set in the refresh response? I'll comb through

supertokens-node

to see what method it's doing to set the cookie

daledigital

04/26/2023, 9:36 AM

Cheers! (you should charge for this btw!)

rp_st

04/26/2023, 9:37 AM

Yes. Also for the sign in / sign up response etc..

rp_st

04/26/2023, 9:37 AM

haha yea.. well.. we do have paid support options. But we really care about users getting it to work - helps us improve stuff and find bugs

daledigital

04/26/2023, 9:39 AM

It seems to have set the cookies for that at least (I'm using a custom provider for LinkedIn OAuth) as they are in the request already

https://cdn.discordapp.com/attachments/1100422802256969788/1100717802521890896/image.png▾

rp_st

04/26/2023, 9:39 AM

right. So i wonder why the refresh API is not setting both the cookies.. weird.

daledigital

04/26/2023, 12:18 PM

Interesting... I added a SuperTokens framework for Qwik instead. It seems as though the access token value containing

is problematic when retrieving the value from a cookie. Here's my access token from SuperTokens:

Copy code

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsInZlcnNpb24iOiIyIn0=.eyJzZXNzaW9uSGFuZGxlIjoiNGIzNjlmZTQtNGQxNC00ODI1LTliYjgtZjM0MWQxMmZlZWM2IiwidXNlcklkIjoiMzYzYzIxNDctMzU5Zi00ODllLWE5YWQtNWY4M2FhMmI1YWZkIiwicmVmcmVzaFRva2VuSGFzaDEiOiJjZTAxZTcwNTFiM2ZiYjgyOTQ3MzM0NmY0N2ViM2MyMWY0MmZiYzkxNDFkMDIxM2M4ZWQ1YWQ1YjZlNTQwZjEzIiwicGFyZW50UmVmcmVzaFRva2VuSGFzaDEiOiI0NDM0OGY3ZjgzMDI2ZjlkNjZjNDMyNjVhMzM1MDJiZWM3MzRiZGRkNzUxMzEwNDdhYjNhNGQyNTVmZmM4NWM2IiwidXNlckRhdGEiOnt9LCJhbnRpQ3NyZlRva2VuIjpudWxsLCJleHBpcnlUaW1lIjoxNjgyNTE0NTkyNDkyLCJ0aW1lQ3JlYXRlZCI6MTY4MjUxMDk5MjQ5MiwibG1ydCI6MTY4MjUxMDk5MjQ5Mn0=.p5z2/F7RjUSVmFWrICLQbl06mL9a6IxEQKrr+14gjdYfRlvg5ODJQxABSvrjZsPv9kxo3mayANffPlzsaMgRMTuSAgTM5NbdXeh0XKWl6WVfA6CAtke9HnHRJPWtK5UnkN2el+puqPGQYECKJJ5M0oeo6zwI4HwtWnMGLFNuWLH8t5CwT/9aKKbOGiROCEB/41YL1+To8FB6zBXmSMn5a4h3Burf2SE9PNjraaxNKSW5LA+x9LiBNKKbaafAGMHTlNos1qNi+tPlf+o//qKGchmZYpnMzx+ny0XQB5iX4Rfp8V7zAlf41jrO+BR92MCX1U98m8qarU10RZeZQQoGwQ==

When fetching the access token from the Qwik City framework, the value is:

Copy code

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsInZlcnNpb24iOiIyIn0

Qwik City is parsing the cookie from the header and splitting the cookie key-values by

rp_st

04/26/2023, 12:21 PM

i think you need to url encode the cookie before setting it. That's what other frameworks do by default.

rp_st

04/26/2023, 12:21 PM

i just logged into my express app and as you can see, the sAccessToken is url encoded

https://cdn.discordapp.com/attachments/1100422802256969788/1100758609647902730/Screenshot_2023-04-26_at_17.51.25.png▾

daledigital

04/26/2023, 12:24 PM

Nice! Qwik also url encodes the cookie value but in their approach, they drop the rest of cookie value after the

: bug in their approach on line 63

https://cdn.discordapp.com/attachments/1100422802256969788/1100759385296355459/image.png▾

rp_st

04/26/2023, 12:25 PM

right.

dlighten08

04/28/2023, 10:17 AM

Hey @rp_st does supertokens init method does the process in sync or async?

rp_st

04/28/2023, 10:17 AM

sync

dlighten08

04/28/2023, 10:17 AM

Okay . Thanks

118 Views

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