https://supertokens.com/ logo
#support-questions
Title
# support-questions
b

Bailey

12/13/2022, 8:08 PM
Hi, I'm having trouble updating the access token payload for multiple sessions. I have variable called
verified
in the access token payload which is set during session creation. At a later time when I want to update this value for all sessions with a given userId, I am doing the following:
Copy code
async function updateAllAccessTokenPayloads(uuid, data) {
    const handles = await getAllSessionHandlesForUser(uuid);
    for (let i = 0; i < handles?.length; i++) {
        await mergeIntoAccessTokenPayload(handles[i], data);
    }
}
On the frontend, I'm getting inconsistent results: After calling
mergeIntoAccessTokenPayload
on each session handle, it doesn't always update the session on the frontend. I noticed that after refreshing the page in Chrome, the supertokens api
/session/refresh
is called every time. But not in other browsers (Edge, Firefox). This
/session/refresh
call causes the frontend to cycle through 2-3 JWTs, some with the correct
verified
value, some unchanged. In Firefox/Edge, the
/session/refresh
call doesn't happen on a page refresh, and it seems to be unaffected by the
mergeIntoAccessTokenPayload
call. I'm continuing with testing to better understand what's happening, but I'm wondering if there's anything wrong with my use of
mergeIntoAccessTokenPayload
. Should these session changes be reflected in the
useSessionContext()
token payload on the frontend after a page refresh? Edit: Until the frontend automatically calls
/session/refresh
, the frontend is using an out of date token payload. After calling
session/refresh
, it has the updated payload.
r

rp

12/14/2022, 2:41 AM
Hey @Bailey
So the frontend session will be updated only after refresh. That’s true.
But it should always reflect the latest payload after refresh. Based on your message, it seems like that’s not happening? But then based on the edit part, it seems like it is?
Also, a page reload shouldn’t cause a refresh each time. Are you using SSR during page reload?
b

Bailey

12/14/2022, 3:01 PM
No SSR. When should the frontend learn that the payload has updated? It only seems to happen after
/session/refresh
is called, but this is only occurring in chrome and it shouldn't be calling it on a page reload. What could cause the frontend to call
/session/refresh
?
r

rp

12/14/2022, 3:02 PM
The front end would know that the payload is updated after a call to the refresh api
And the refresh api should only be called after the access token has expired. By default, The access token lifetime is 2 hours
So fist we need to see why chrome is calling refresh on every page load. That shouldn’t be happening. Have you initialised supertokens with the session recipe on the frontend? What is the cookie store on chrome after you login?
b

Bailey

12/14/2022, 3:36 PM
I'm using EmailVerification, EmailPassword, Passwordless for 2fa, and Session
After a signin, I have these cookies
r

rp

12/14/2022, 3:37 PM
Right. So this seems fine
When you reload the page, what are the requests that are made? Does any api return 401?
b

Bailey

12/14/2022, 3:43 PM
None return a 401, I'm currently testing on a blank page that just lets me call the backend to make the request to change the token payload. I'm getting different results though because the /refresh route isn't being called on this page. Trying to figure out what is causing that to be called
r

rp

12/14/2022, 3:44 PM
hmmm. If you are using the supertokens-auth-react SDK, try wrapping this page with the wrapper - what happens?
b

Bailey

12/14/2022, 3:46 PM
If I use session auth around one of the normal routes I have this problem with it seems to act the same. And when I use it around my test route it doesn't do anything different there either.
r

rp

12/14/2022, 3:46 PM
interesting.
do you call the attemptRefreshingSession function?
i guess not.. cause if you did, it would refresh on firefox as well.
can you enable frontend debug logs and show me the output on page reload?
b

Bailey

12/14/2022, 3:59 PM
The logs I could send are a bit messy. I'm currently trying to reproduce the issue I'm seeing on a test page so that the logs are only updating as needed to reproduce the issue
r

rp

12/14/2022, 3:59 PM
Okay!
If you can’t figure it out, I’d be happy to jump on a debugging call
You can book a call via our website
b

Bailey

12/14/2022, 4:01 PM
Thank you, i'll message back here once I have some more info
r

rp

12/14/2022, 4:02 PM
Also, tagging in @porcellus here who might be able to help as well
b

Bailey

12/14/2022, 4:55 PM
Not sure how useful these logs will be. This was an example where the frontend received multiple JWTs. I can't figure out how to consistently reproduce this issue, but I am seeing the issue happen in Edge as well. The frontend is receiving a new JWT when
/session/refresh
is called, and also
/user/email/verify
. I'm not sure why the verify route is being called.
The logs have been slightly updated to remove any personal information from the payload, and the JWT has been replaced by [JWT - #], # incremented if it's different than the other JWT values
In my test component, I'm seeing it cycle through 3 different JWTs. In that test component, I'm calling 1 backend API (/notification/getRecent). And it's also calling
/user/email/verify
automatically, but I'm not sure why this API would be called.
To clarify, previously you said that the updated access token payload would only be noticed by the frontend after calling
/session/refresh
, so
mergeIntoAccessTokenPayload
isn't intended to update the frontend when the merge request is made, but instead when a new access token is generated? It seems like I have an unrelated issue I'm going to try to debug, but the merge function isn't going to address the issue I was trying to solve. Is there a method to update all frontend token payloads for a user without having to wait for their existing token to expire?
r

rp

12/14/2022, 5:56 PM
There are two mergeIntoAccessToken payload functions. One on the session object that’s a result of session verification. This has an effect on the current session on the frontend immediately. And one of the sessionHandle, which you are using. This has an effect on the session tokens on the frontend when they refresh.
There is no way to update all the frontend tokens cause they are stored on the frontend. You could make the tokens update faster by reducing the access token lifetime
Which version of the frontend and backend SDKs are you using?
b

Bailey

12/14/2022, 5:59 PM
Copy code
frontend: "supertokens-auth-react": "^0.27.1"
backend: "supertokens-node": "^12.1.0"
r

rp

12/14/2022, 6:00 PM
The email that you signed in with, is that unverified?
I mean did u finish the email verification flow for that email?
b

Bailey

12/14/2022, 6:01 PM
It's marked as verified in the dashboard
r

rp

12/14/2022, 6:02 PM
I see. So if you login again, it should not call the email verify API every time on page reload. Is that API still being called?
Oh.
I think I know what’s happening
The API is returning a 304
We don’t return that status code
Do you have some sort of a cache / proxy in the middle?
b

Bailey

12/14/2022, 6:04 PM
I don't believe I have anything set up to do that locally, but 304 is often returned from repeat api calls. After using ctrl+f5 for a full refresh in the browser it stopped giving me multiple JWTs.
r

rp

12/14/2022, 6:05 PM
You might wanna see what is resulting in 304
b

Bailey

12/14/2022, 6:05 PM
I don't know what configuration would cause it to cache other than the default express settings
r

rp

12/14/2022, 6:05 PM
You might be using some middleware in express. Maybe add that middleware after our middleware
Cause returning 304 for these APIs results in unexpected behaviours - like the one you are seeing
b

Bailey

12/14/2022, 6:06 PM
That would make sense, I'll see if I can find what's causing it
r

rp

12/14/2022, 6:07 PM
Yup. Once you solve this issue, I think things should work as expected.
If not, we are here to help 🙂
b

Bailey

12/14/2022, 6:10 PM
Well... Caching definitely seems like the cause. Quick test with
app.disable('etag');
seems to be working as intended.
Thanks for the help 🙂 lol
r

rp

12/14/2022, 6:11 PM
Right ! So this has happened in the past with other users. For them, the 304 were coming cause they were using the react proxy feature to load the react app on a different port than the web server (which was also the same as the api server)
b

Bailey

12/14/2022, 6:12 PM
Thanks again, will keep that in mind too
r

rp

12/14/2022, 6:13 PM
👍
7 Views