https://supertokens.com/
Join Discord
I have an odd scenario: On local a successful signup will assign `sIRTFrontend` `sFrontToken` `sIdRe...
# support-questions-legacy
n
I have an odd scenario: On local a successful signup will assign 
sIRTFrontend
sFrontToken
sIdRefreshToken
and 
sAccessToken
cookies and store them on the browser. On prod a successful signup will only assign 
sIRTFrontend
and 
sFrontToken
In both cases the user is added to the db under the correct (emailpassword) recipe. If I navigate to 
/auth
on prod, I'm still redirected to 
/
, so the 
EmailPasswordAuth
component is still detecting some sort of logged in session but the cookies are not present or working in the browser cookies nor being transferred with the request credentials. This all works on local. I cannot for the life of me, figure out why the local implementation would be different?
Actually seems that the cookies are being stored with a different domain api.xyz.io (api domain) instead of beta.xyz.io (browser domain) and are being removed by the browser. hmm..
sAccessToken
and 
sIdRefreshToken
are being stored according to the domain of my backend instead of the domain of my frontend :/
r
that's expected.
which cookies are being removed?
n
sAccessToken
and 
sIdRefreshToken
are being removed
sIRTFrontend and sFrontToken have domain beta.mysite.com sAccessToken and sIdRefreshToken have domain api.mysite.com browser is accessing beta.mysite.com, signup on beta.mysite.com/auth post-signup, using nextjs router, change route from /auth to /foobar cookies with domain api.mysite.com are being removed by the browser (or something)
r
The browse can’t remove them cause they are controlled by the backend.
Can you enable backend debug logs and show me the output please?
n
Browser can't remove them what does that mean? Because that doesn't make sense in terms of the data flow: 1. signup 2. success response and store cookies on browser 3. navigate to new route 4. getServerSideProps calls API 5. API call fails because cookies are missing In this flow how would the backend interact with the browser between storing the cookies and navigation to a new route?
r
Oh right. I see. So getServerSideProps happens on beta.xyz.io correct?
n
Btw transfer of cookies to getServerSideProps is not the issue, because they are partially present on the getServerSideProps (i.e. sIRTFrontend sFrontToken are set)
Yeah server side props is on beta.xyz.io
more accurately the next server is on beta.xyz.io
r
For sAccessToken to go to that sub domain, you need to set a config value on the backend.
Cause right now, the sAccessToken only goes to api.xyz.io
So you need to set it up so that cookies are shared across multiple domains
n
I've set sessionScope to 
.xyz.io
on FE config
r
That’s a different setting
This is the cookieDomain setting.
This will enable the access token to get sent to beta.xyz.io as well, making getServerSideProps work.
n
Cool beans
r
After setting this, you need to relogin
n
Ok I'll try it out now
to clarify whats the best pattern here, right now I'm just passing req.headers.cookie from the getServerSideProps into the request made by getServerSide props to api.xyz.io - where my actual API is hosted - wondering if this multi API pattern still applies
r
It does apply. What you need to take care of is that api.xyz.io can return a 401 to the getServerSideProps function. And that should be propagated back to the client in the same way as you are propagating the try refresh token error (as shown in the docs)
n
err: Error: SuperTokens core threw an error for a GET request to path: '/apiversion' with status code: 401 and message: Invalid API key
r
Check the api key you have provided on the backend
n
yeah doing that now, just wondering if you can pass through the getSession API but looks not
in this pattern seems you can really only call session.getSession()? What if you want to on call the core API at api.xyz.io, I'm guessing you need to set the cookie headers manually from the returned session or something?
r
Yea. You will have to set the cookies headers manually in this case.
n
And which cookies is the backend looking for at a minimum, is it enough just to send the access token or do you need all 4 sIRTFrontend sFrontToken sIdRefreshToken and sAccessToken
r
Access token and sIdRefreshToken. That’s it
PreviousNext
Powered by

SuperTokens.com

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

Powered by