https://supertokens.com/ logo
Title
a

Axel Jönsson

12/05/2022, 12:16 PM
Hi guys! I've come across a pretty strange behavior. I'm using the SDK in a react native app. In order to maintain the session state i routinely check "SuperTokens.doesSessionExist()" and with that answer go forward with an authorized/unauthorized user. What i have discovered is that when the session expires, the method "doesSessionExist", still resolves true.
r

rp

12/05/2022, 12:17 PM
hey @Axel Jönsson
a

Axel Jönsson

12/05/2022, 12:17 PM
Yo!
r

rp

12/05/2022, 12:17 PM
when the session expires meaning that the access token has expired? or that the refresh token has expired too?
a

Axel Jönsson

12/05/2022, 12:23 PM
no, its the access token. Because i can run the "attemptRefreshingSession()" method instead of "doesSessionExist()" as a work around
r

rp

12/05/2022, 12:27 PM
right yea. So in this case, a session does exist. It's just that the access token has expired.
a session fails to exist when the refresh token was revoked or has expired.
a

Axel Jönsson

12/05/2022, 12:34 PM
ok that explains it actually, what is your recommendation if i just want a simple way to check if a session is valid?
Should i go for "getUserId()"? if it is an empty string the session is false? or something like that?
r

rp

12/05/2022, 12:36 PM
not really. You shouldn't have to worry about access token expiration. Just use the functions freely. Refreshing happens on its own
a

Axel Jönsson

12/05/2022, 12:38 PM
huh, that sparks a couple of questions. Refreshing happens on its own?
r

rp

12/05/2022, 12:38 PM
yea. Are you using axios?
if so, you need to add our axios interceptors to your axios instance
and then it will do auto refresh when you make an API call
a

Axel Jönsson

12/05/2022, 12:39 PM
ooh, ok. No i have a simple fetch call right now. Was hoping to make use of your coming fix to intercept apollo requests
r

rp

12/05/2022, 12:40 PM
fetch interception also should happen on its own
a

Axel Jönsson

12/05/2022, 12:40 PM
hmm
r

rp

12/05/2022, 12:40 PM
as long as you called session.init
a

Axel Jönsson

12/05/2022, 12:40 PM
yep
wait, session.init?
r

rp

12/05/2022, 12:41 PM
in the request that you make, what are all the headers that sent in the request?
> wait, session.init? Oh sorry
just supertokens.init
a

Axel Jönsson

12/05/2022, 12:41 PM
ye
hehe
with a google login i send:
headers: { 'Content-Type': 'application/json', rid: 'emailpassword', },
r

rp

12/05/2022, 12:43 PM
right. So interception is happening
oh wait no..
i mean can you show me the request headers for an API call to one of your APIs?
a

Axel Jönsson

12/05/2022, 12:43 PM
yeah
r

rp

12/05/2022, 12:43 PM
that you call using fetch
post login
a

Axel Jönsson

12/05/2022, 12:48 PM
r

rp

12/05/2022, 12:48 PM
right. So interception is happening
now if the API returns 401, does it not call the refresh APi?
a

Axel Jönsson

12/05/2022, 12:50 PM
no, i've tried it locally with an expiry timer on 1 min. And i have to manually call refresh in order to get it to do exactly that
r

rp

12/05/2022, 12:50 PM
hmm. Does the API return a 401 if the access token has expired?
a

Axel Jönsson

12/05/2022, 12:50 PM
call "attemptRefreshing.."
hmm.. that i haven't tried actually
or checked rather
r

rp

12/05/2022, 12:51 PM
so you should let the access token expire and then call an API that uses verifySession. That API should return a 401 which should trigger a refresh API call on its own
so you don't need to call "attemptRefreshing.."
a

Axel Jönsson

12/05/2022, 12:53 PM
I have to check how it is done in the backend. It's not me who set that part up
r

rp

12/05/2022, 12:53 PM
right. All you should see is that the API returns a 401 when access token has expired or is missing
a

Axel Jönsson

12/05/2022, 12:54 PM
aight, give me a couple of mins
have to set things up locally
ok
so i did not get a 401 back
i only got an error from hasura, saying "code: access-denied"
so maybe it is the hasura middle layer interrupting me again
?
But i gues that that is good enough. "code: access-denied" is the translation of 401, so i can handle that error in the client side.
r

rp

12/05/2022, 1:40 PM
yea. but it's better for the backend to send 401
you shouldn't have to handle refreshing on your frontend
a

Axel Jönsson

12/05/2022, 1:54 PM
I fully agree but with the requests going through hasura i dont really see a better way for now.
But at least now i know how it works
So a huge thanks for the help today! I
You'll probably hear from me again sometime 🙂 Merry christmas!
r

rp

12/05/2022, 1:59 PM
sounds good 🙂