https://supertokens.com/ logo
Join Discord
Powered by
Hello, we have a NextJS / Hasura app / cookie base...
# support-questions-legacy
d
Hello, we have a NextJS / Hasura app / cookie based and are having issues refreshing tokens for current sessions during our upgrade to 
5.0
in our development environment. Wondering if you have any ideas. Our hosted 
core
instance was upgraded to 
5.0
this morning. That seemed successful, so we deployed the changes to our backend SDK (package version + config changes) and client (JWT fetching) from the change logs. Now all our users are getting a 
Could not verify JWT: JWTExpired
error from Hasura when it attempts to validate the token. This is for people who had an ongoing SuperTokens session. Versions: - 
supertokens-core
: 
4.6
to 
5.0
- 
supertokens-node
: 
^13.5.0
to 
14.x
- still on 
supertokens-web-js
^0.5.0
Clearing site cookies allows our users access again. We can't ask our production users to do that though, so we're trying to understand the cause.
Decoding either 
sAccessToken
or 
st-access-token
, they both appear to be in the newer token format... but with an added 
jwt
field. The 
exp
value on the cookie is not expired. But decoding the nested 
jwt
value, that one is expired. Should the nested 
jwt
be there? It seems to break the seamles upgrade path behavior for users with older valid tokens. Since it checks for a 
jwt
and finds it. If the nested 
jwt
weren't there I think it would use the new 
getAccessToken
method instead.
r
hey @diana.holland
newer issued access tokens should not have the nested JWT in it. On the frontend, you should check if the access token payload contains the 
jwt
key and if it does, use that to send to hasura (since those are still older sessions). If it does not, then use session.getAccessToken on the frontend to get the jwt from the newer session. Once the older sessions refresh, their tokens will be upgraded to not have the nested JWT.
This assumes that you send the access token as an authorization header - is that the case?
d
Interesting! That's what I expected. Please see the screen shot -- the decoded 
sAccesstoken
and 
st-access-token
is the newer version that's not supposed to have a jwt, but it also has a nested jwt within it.
We are performing that check on the frontend
Yes we do send the access token as an authorization header
r
can you open an issue about this please? Maybe what you can do to fix this in the mean time is that you can override the refresh API on the backend SDK, and then post successful refresh, check if the session.getAccessTokenPayload() has a 
jwt
field in it, and if it does, use 
session.mergeIntoAccessTokenPayload({jwt: null})
d
Okay I'll look into that and open an issue, thank you!
Which package is best for the issue? The backend SDK?
r
node SDK
d
r
thanks!
lmk if the refresh override method works for you
7 Views
PreviousNext
Powered by