https://supertokens.com/ logo
Join Discord
Powered by
Has anyone found that when they're logged in with ...
# support-questions-legacy
p
Has anyone found that when they're logged in with super tokens and the backend is verifying their ID, that after they move off the frontend tab for a bit and come back, the userId is rendered as null on the backend? But then when the frontend is refreshed, the userId is correctly set again
r
hey @predev_77816
are you manually sending a 401 from your API?
the veirfy API i mean
p
no im not
on the backend i temporarily changed the cookie domain
and it worked fine on localhost
r
right.
p
but then in production it bricked
and then i reverted
r
yea.. that changing og cookie domain will break things
since older access token will be sent, and not refreshed
what was the value of the cookie domain before, and what did you change it to?
p
it was empty
i changed it to https://pre.dev
and then i reverted it again
r
why did you add this value?
i mean any reason to set it to this vallue?
p
i was trying to fix the issue of that after 5/10 minutes, the userId was getting set to null.
r
right
userId being null. Im not quite sure why that would happen
or how that can even happen
as long as you used to send the access token in the request, the user id comes from that
p
yeah its really odd, it happens by itself after 5/10 minutes.
but in the meantime
how can i fix this verifyIssue
try refresh token*
r
so you should set the cookie domain back to being not set
p
i did
and its still happening
r
clear all the cookies for your website and login again
about the user id being null, im going to need more info on that to help out
p
is there a way we can programatically do that for all of our users? a bunch of users are facing this.
r
Yea.
p
but only if they are getting the 'try refresh token issue'
r
it will require a few customisations on the backend on your end
which backend sdk are you using of ours?
p
supertokens-node
its express + apollo graphql based
r
and which node framework?
pl
ok*
what you want to do is to write your own middleware that runs before anything (even before the supertokens middleware), to check if there are two sAccessToken cookies in the request
and if there are, then set, in the response, sAccessToken cookie to an empty value, with an expired date, with the cookie path being 
/
, and the cookieDomain being 
pre.dev
(or whateber you had changed it to in the middle sometime ago).
You can see this on how to remove a cookie: https://stackoverflow.com/questions/27978868/destroy-cookie-nodejs. Make sure that the cookie you remove has the cookieDomain that you had set in the middle
p
so i tried clearing all the cookies on the frontend manually in chrome developer console
but its still doing this try refresh token on our end
r
how did you clear the cookies?
sometimes chrome doesnt show all the cookies and you don't end up clearing all of them
the issue is that you have ended up setting 2 access tokens, against two different cookieDomain values
p
const cookies = document.cookie.split(';'); for (const cookie of cookies) { const eqPos = cookie.indexOf('='); const name = eqPos > -1 ? cookie.substr(0, eqPos) : cookie; document.cookie = `${name}=;expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/`; }
r
that won't work
that only clears frontend cookies
but the access token is a backend cookie
anyway, try what i said. Lmk if that works or not
p
yeah im kind of at a loss here, if you have a code snippet or something i could work off of that would be great
r
i sent a link above
SO link
p
is there any simpler way, the back and forth of waiting to test on production is going to take way too much time. could I just clear all cookies somehow? force everyone to relogin.
r
you could switch to header based auth on the backend. The will log everyone off immediately. But then switching to cookie based auth after might cause the same issue with those same users.
p
ok yeah how can i do that? right now cookie based auth is turned off.
r
make this config change on the backend and push that to prod.
all users will be logged out.
p
ok
is this only a specific version of supertokens? i'm getting an error that its not a field that can be set within the session.init
r
are you setting this on the backend?
which version of the node sdk are you using?
p
yep
"supertokens-node": "^16.7.1",
r
on the backend, the config is 
getTokenTransferMethod: () => "header",
as shown in the docs
p
my bad
r
did the setting solve this issue?
oh, and one thing. Using header based auth will prevent session verification during SSR. Is this something you need to use?
p
no we don't use SSR
i really appreciate the help man
the header based auth worked well
r
happy to help!
ok nice
p
we are now back up and running
r
now, onto the other issue
p
yes
r
the user id being null
do you have any more info on what you mean by when u say the user id is null
cause when you do session.getUserId() from the session object thats a result of the verifySession or getSession function call, it cannot return null.
even froma types point of view, getUserId() function always returns a string
p
so this is what our middleware looks like (we have an integration with atlassian too) -> app.use( express.json(), expressMiddleware(server, { context: async ({ req, res }) => { try { // let refresh = await Session.refreshSession(req, res); // console.log({ refresh }); let session = await Session.getSession(req, res, { sessionRequired: false }); const userId = session !== undefined ? session.getUserId() : undefined; if (userId) { const { metadata } = await UserMetadata.getUserMetadata(userId); return { userId, ip: req.ip, atlassianToken: metadata.atlassianToken, atlassianUserId: metadata.atlassianUserId, atlassianRefresh: metadata.atlassianRefresh, expires: metadata.expires }; } else { return { userId, ip: req.ip }; } } catch () {} } }) );
r
ok right. so you do 
sessionRequired: false
so the value of 
userId
can be undefined if 
session
is undefined.
And 
session
can only be undefined here is the access token passed to the request is missing, or was not issued by supertokens
p
interesting, so if there was say a 5/10 minute gap between when the user last did a request and now sends a new one, would the access token not refresh?
r
well, now it would be if the authorization bearer token is missing or is a token that;s not issued by supertokens (given that you are using header based auth)
p
ok interesting
r
> would the access token not refresh? It would be. Cause the access token would still be in the header, just expired. This would tell getSession to throw an error, which.. oh i see
you are catching all exceptions and doing nothing
thats the issue
or at least, an issue
what you want to do in the try / catch is to do next(err) and let the error go to our errorHandler, which will send a 401 to the frontend -> trigger a session refresh
now im not even sure how the verify endpoint you had was sending a 401.. given that you are doing nothing in the catch block. Weird.
p
ahh i truncated the catch
here it is
} catch (err) { if (Session.Error.isErrorFromSuperTokens(err)) { console.log({ err }); // throw new GraphQLError("Session related error", { // extensions: { // code: "UNAUTHENTICATED", // http: { // status: err.type === Session.Error.INVALID_CLAIMS ? 403 : 401, // }, // }, // }); } console.log('Express context error'); console.log({ err }); return { userId: undefined, ip: req.ip }; }
but yeah same thing
r
yup
you want to do:
Copy code
if (Session.Error.isErrorFromSuperTokens(err)) {
   return next(err)
} else {
   console.log({ err });
                    return {
                        userId: undefined,
                        ip: req.ip
                    };
}
and the next(err) would call our error handler as long as you have added it to your app (which is a part of our setup instrs)
p
ahhh nice, i don't have acces to 'next' as function. in this middleware
r
all express middleward have 
next
anyway, you can send a 401 manually to the frontend too
p
nice ok cool
r
p
yeah ill just use res.status
r
yea.
see the link i sent above though
so now, when the frontend gets a 401, it should do a refresh.
and the our sdk would retrigger the api with the new access token -> and this time, the getSession would not throw
btw, did you set the access token lifetime to be 5 or 10 mins or something?
p
sorry was just on a sales call
hmmm not that i see anywhere
r
Right. So I’m not sure why the 5-10 mins would make a diff
Anyway, see if the error comes again. And if it does, reach out. I’ll be happy to help then. Sometime tomorrow perhaps
8 Views
PreviousNext
Powered by