https://supertokens.com/ logo
Join Discord
Powered by
Just wanted to ask, if we have to do custom implem...
# support-questions-legacy
m
Just wanted to ask, if we have to do custom implementation of Session verification on the backend in case standard request response objects are not available, how can we do that?
r
hey @mib200
at the moment, we don't. You need to use our verifySession or getSession function. But soon (in a few weeks time), we will have a way. So stay tuned.
m
I was thinking, can't we extend those functions?
r
you can make your own request and response wrapper for those functions that works with your framework
m
My exact use case is that when I am unable to find cookies on the backend, I should be able to set new cookies without the user being redirected to login page
r
why would you not be able to find cookies?
m
after he is redirected to login page, the front end SDK refreshes the session and user goes back into protected pages
but this looks quite glitchy
r
right. So does the frontend request send the cookies in the API call?
m
I check for 
sFrontToken
in the backend cookies
r
that won't exist
m
and when it is not available, the user is redirected to login page
r
you need to see the sAccessToken and sIdRefresgToken
m
correct, by the way, I am using this in sub-domain context
so I only have 
sFrontToken
and one other cookie
surprisingly, the frontend somehow re-establishes the session even when this cookie is expired and removed from frontend... And again, this is on a sub domain context.
r
so sFrontTokens is not meant for the backend
the backend should only care about sAccessToken really
so make sure that that's being sent by the browser.
or the sRefreshToken in case of the refresh API
m
but that is not available to a sub-domain. So if auth was done for "auth.example.com", 
sAccessToken
is available on that domain The cookies available on "internal.example.com" does not have the above cookie. It only receives 
sFrontToken
As the documentation says: `sFrontToken`: Used to access a session's access token payload and user ID on the frontend without exposing the 
sAccessToken
.
this is maybe for sub-domain security
r
oh you can make it available on sub domains as well
sFrontToken should not be used for verifying access since it's not signed. Stick to using the sAccessToken
m
let me double check this
maybe I configured something wrong
strange
@rp_st you are right! Cookies can be exposed to subdomains
I was declaring session scope
cookie domain definition was missing
r
great!
m
@rp_st another quick question. Now that I have these cookie tokens in backend, and I don't have any way to use Session method from node SDK on AstroJS to get session
what do you suggest, how should get the tokens refreshed from the backend call itself in SSR
r
yeaa.. so that goes back to my initial message
m
instead of waiting for frontend to refresh it
r
you can't get tokens refreshed from backend
cause the refresh token is only available on the frontend
m
But we do get 
sIdRefreshToken
in backend
from cookies
r
thats not the refresh token
even though it has a similar name
the refresh token is 
sRefreshTokens
and is only sent on the refresh API path
so if the access token is expired or missing, send back a 401
and the frontend will call the refresh API
Now about support for astroJS, you should create a wrapper for that like how we have for express
m
ok, so no rolling session is possible from backend. This has to be done from the frontend only
r
yea
m
Last question, where is this 
sRefreshTokens
stored on frontend
I can't see it in cookies
r
Navigate to the api domain on the refresh API path on your browser
you will see it then
are you using our SDK with a different backedn thats not AstroJS?
like with express?
m
Yes, I am using your example from NextJS
r
right i see
and a different astrojs backend?
m
backend and frontend both on nestjs
connection URI as https://try.supertokens.com
nextJS I meant
r
right
so where does astroJS come in?
cause you mentioned that before
m
that is a different project where I am trying to do the same thing using the same methods since I am not very fond of NextJS
r
ahh i see
m
my apologies for the confusion
r
haha no worries
m
@rp_st so where do I get these? 
sRefreshTokens
r
the browser will send this to the backend when you call the referesh API
m
I meant where can I see them in browser. They are not in cookie storage. Just want to understand the flow, coz if they are being sent to server with some data, and that data is not there in browser, how tokens are getting refreshed.
r
it is on the browser cookies for dsure
navigate to api domain and to the refresh API path
PreviousNext
Powered by