https://supertokens.com/
Join Discord
Hey, I'm using React/NextJS (email/password recipe) + Nodejs in the back. I keep in my token the cur...
# support-questions-legacy
h
Hey, I'm using React/NextJS (email/password recipe) + Nodejs in the back. I keep in my token the currAccountId of the logged user. When the current user switches from account, I update through the backend with mergeIntoAccessTokenPayload the currAccountId. This according to the doc should reflect automatically the changes in the front but it's not the case. If I do a console on the output of the accessTokenPayload the currAccountId is not always the updated value. While navigating through the pages, it sometimes gets updated & it sometimes keeps the old value ... what do I do wrong ? Can I force the token to refresh in the front ? Thanks! After some time the token is refreshed in the front, but it's not immediate!
r
hey @hhchift
how are you calling this function? On the session object or passing it a sessionHandle? Can you show me an example of how you are calling this function?
h
mergeIntoAccessTokenPayload ?
Copy code
await req.session.mergeIntoAccessTokenPayload({
                    currAccountId: newAccount,
                    currEnvId: defaultEnvId,
                });

                await req.session.fetchAndSetClaim(UserRoleClaim, {
                    session: req.session,
                });
                await req.session.fetchAndSetClaim(PermissionClaim, {
                    session: req.session,
                });
r
Right, and this sometimes works and sometimes doesn’t?
Can you show me the request and response headers when this API is called?
h
Exactly there is no error, but sometimes it gets refreshed automatically on the front, sometimes not ... sometimes after some time
How can I get the headers of the mergeIntoAccessTokenPayload call ?
r
From the chrome’s network tab
When the api call is made. Chrome will show it in the network tab
h
OPTIONS /v2/users/changeaccount HTTP/1.1 Accept: / Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9 Access-Control-Request-Headers: content-type,rid Access-Control-Request-Method: POST Connection: keep-alive Host: localhost:4000 Origin: http://localhost:8080 Referer: http://localhost:8080/ Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-site User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36
HTTP/1.1 204 No Content X-Powered-By: Express Access-Control-Allow-Origin: http://localhost:8080 Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE Access-Control-Allow-Headers: content-type,rid Access-Control-Allow-Credentials: true Vary: Origin, Access-Control-Request-Headers Content-Length: 0 Date: Thu, 16 Mar 2023 12:29:22 GMT Connection: keep-alive Keep-Alive: timeout=5
is that what you want ?
r
which version of the frontend sdk are you using
?
and the backend sdk
h
last one, I just updated
"supertokens-auth-react": "^0.31.2"
"supertokens-node": "^13.1.4",
r
@porcellus can help here maybe
h
I just retrieve the payload in the front as such : const { accessTokenPayload } = useSessionContext() as LoadedSessionContext; directly in a functional component
r
Can you print out the value of 
req.session.getAccessTokenPayload()
between each of the session updates you do? What is the output?
Can you print out the value of req.session.getAccessTokenPayload() between each of the session updates you do? What is the output?
h
Copy code
{
  currAccountId: '85b00a63-8597-4f1e-850e-d84f6831ad44'
}
-> merge
{
  currAccountId: '00fc1383-b743-4c9c-8cd6-a90a3dc811e0'
}

second time:
{
  currAccountId: '00fc1383-b743-4c9c-8cd6-a90a3dc811e0'
}

-> merge
{
  currAccountId: '00fc1383-b743-4c9c-8cd6-a90a3dc811e0'
}
in the backend it seems ok
this is because the second time I request to change back to 00fc ... as the token is still 85b00 ...
r
And what are the response headers associated with this api call?
p
hmm, the 
UserRoleClaim
and 
PermissionClaim
didn't appear in there, they should be there if they have a value
h
they are
I just rmoved them
the token is now refreshed on the front (I was just navigating)
If I switch again of account
the currAccountId is now moved back. to 85b ...
so it took like 1-2 min before it was correctly set to the new token
p
just for debugging, could you try adding a 
lastRefresh: new Date().toUTCString()
next to the 
currAccountId
into the access token payload?
h
and print the value from the front ?
p
yeah, both frontend and backend
h
I added the lastRefresh
directly after the switch
I have the lastRefresh in the token
but then when navigating the lastRefresh is gone (in the front)
and currAccountId on the old value
r
Do you have some sort of proxy in the middle of the frontend and backend?
h
and again only now the lastRefresh is in the front
No
NodeJS express on the back
using react query for some queries in the front
if you want we can do a screen sharing session
p
That may be best, I'll send you a calendly link in a min. A few questions meanwhile: - are there any requests or only the client side navigation when the token seems to revert? Anything that has a front-token header could be interesting. - how are your domains set up? is everything on the same domain? - are you doing SSR?
h
1) I will look into this, but not realy that I directly know of
2) Same domain, but here it's on localhost
3) No SSR
p
Sorry it took this long, but my event types/links seem to be gone somehow, I had to re-create it.
h
@porcellus sorry my call ws in 30 min
I can go back in the zoom
if you want
p
ah ok
let's go back 🙂
h
Hello, so we found out that desactivating e-tag would prevent this issue from happening. We found out that the token was reset due to a another request using the caching and resetting the token... but now I'm wondering:
- Is it not bad practice to use eTag when you use cookies to contain the token payload ? this could happen to any other requests ...
- Why is the token reset in a cached response ?
- Would it not be better to always avoid setting cookies/headers in cached response ?
It seems to me that it's almost something that should be included by default in the sdk of supertokens of express: if etag is used, if a response is using the cache, you should never update the cookie ... is this possible ?
r
@porcellus - what do you think?
p
hi
I don't think that's in our control
- cookies are not included in the cached response so that's not really the issue. The issue is that this caching mechanism is a bit too aggressive, I'll have to check it out how it works in more detail - the token is reset by the cached response because the response has a stale 
front-token
header from the cache - it would, but the cache is set up by your app (or in this case by the lib your app uses), I'm not sure how well we can control it
h
And why it is the stale front-token included in the header if there is no mergeIntoAccessToken call in this backend function?
r
that's the caching part kicking in and adding it to the response i think (even when it should not be there).
h
yeah that's strange as it is should never be added to that call even in the first call (when there is no cache)
r
yeaa. Very strange indeed.
h
that's why according to me a good solution would be to avoid any setting of cookie when a cashed response is used ,
r
This doesn't really have anything to do with cookies though. Cause the front-token header is not a cookie. This seems like a bug in the caching library being used.
2 Views
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