https://supertokens.com/ logo
Join Discord
Powered by
missing cookies
# support-questions
z
this is really baffling to me but maybe someone has an idea, I'm trying to move to ESM and all of a sudden, 
createNewSession
from the Recipe Session of the 
supertokens-node
SDK cannot set the cookies, not really sure what's going on I can see the sessions getting created in the table, but the cookies doesn't get set
r
hey @ZeferiniX which version of the SDK are you using?
z
"supertokens-node": "13.4.1"
with docker image supertokens/supertokens-postgresql:4.6
r
right. When making the request to sign in, are you setting the 
st-auth-mode: "cookie"
header in the request?
our frontend SDK set's this by default, but in case you are not using our frontend SDK, or querying the API manually, then you need to set this header.
z
r
by default the createNewSession function uses non cookie based session
so you need to set this header in the request and then it will set it in cookies instead
z
let me try
oh that worked but it only sets the access token, I recall seeing a refresh token is this expected?
r
refresh token should also be set. See the response headers
z
oh, so this wasn't related to ESM at all, my bad
r
yea
z
I suppose the Frontend SDKs automatically grabs that but previously, the Backend SDKs sets these server-side
r
that happens now as well.
z
well that's weird, I only see the access token in the cookie page of devtools
r
in the response headers?
to see the refresh token, you have to navigate to the refresh token path on your api domain
chrome deosn't show it otherwise
z
it's in the response headers as well
oh
r
yup
z
is this documented somewhere?
other than this, I couldn't figure this out xD
r
> is this documented somewhere? The migration? That's in the changelog of the SDKs on our github.
z
no, the 
st-auth-mode
requirement and navigating to the refresh token path back in v12, the 
sAccessToken
and 
sRefreshToken
just gets set also checked the changelog and the initial impression I got was just simply passing the 
req
object as well in the 
createNewSession
https://github.com/supertokens/supertokens-node/blob/master/CHANGELOG.md#1300---2023-02-01
r
so in v12, the refresh token behaviour was the same (you had to navigate to the refresh path as well)
z
we have a workaround in our local dev env backend where we expose a GET endpoint that automatically logs in a superadmin when it gets hit, the access and refresh tokens just gets set and seen in chrome dev tools but in v13, that's not the case anymore
thus the question
r
im quite sure that the refresh token behaviour is the same as before
the only diff is that now you need to set st-auth-mode header in the request (which our frontend sdk does on its own)
z

https://cdn.discordapp.com/attachments/1096804291022438411/1096815916609708143/chrome_2023_04_15_231435387.gif▾

from this GIF, I hit the GET endpoint and only the 
sAccessToken
gets set with the 
st-auth-mode
header set to cookie
in v12, both access and refresh tokens gets set
r
you need to navigate to the apidomain/auth/session/refresh on the browser and you will see the refreesh token
this is a chrome thing
not a supertokens thing
cause refresh token is being set. Chrome isn't showing it unless you navigate to the refresh path
you can try firefox instead and you will see
cause firefox shows all cookies for a domain regardless of the path
z
ohh..

https://cdn.discordapp.com/attachments/1096804291022438411/1096817072933175296/image.png▾

that cookie has a path value now in v13 is what you meant
r
it used to have a path before as well
z
wait really
r
again, this is a chrome thing..
yup
z
damn
r
anyhow, hope this helped 🙂
z
yeah I see it on firefox, welp, I'll look into this chrome quirk
thank you very much!
PreviousNext
Powered by