that works just fine

for dev, you will need to use the localhost values.. and for prod, use the https://api.company.com and https://www.company.com values

i'm working through the request flow for when an access token is expired. I'm thinking of updating this session recipe so that it returns a 440 response if the session is expired. the front end will look for this and if detected, the front end will call a 'refresh' endpoint on our backend at which point we will call

Session.refreshSession

and return a response. are there any issues with just passing in this config for the Session recipe during setup on the backend?

{
      sessionExpiredStatusCode: 440,
}

i ask because of the info found on this page: https://github.com/supertokens/frontend-driver-interface/blob/master/v1.5.0.md#refresh-session i would like to focus on using the routes that we've defined instead of relying on default behaviour that may be applied in the front-end or back-end sdks

you can set

sessionExpiredStatusCode

to 440.. but be sure to set this on the frontend and backend SDKs.

is the Session.verifySession() necessary for our /refresh route? i imagine if the accessToken is expired, the verifySession call would fail

No. That’s not necessary.

I mean u shouldn’t use that in the refresh route

i see the config regarding the

sessionExpiredStatusCode

one thing that's not clear to me is how the token refresh flow works given that the sdk is trying to control part of this

We add axios / fetch interceptors and when any of your API calls returns 440, we call the refresh API

the refresh API is a POST request to {apiDomain}/{apiBasePath}/session/refresh

So if you are implementing your own refresh route, you need to give it the route: {apiBasePath}/session/refresh

i see, so you cannot change that route?

and you also need to set

disableDefaultImplementation

to

false

> so you cannot change that route? You can't change the "/session/refresh" part of the route. But you can change the apiBasePath.. so if you set the apiBasePath to "/auth", then the refresh route becomes "/auth/session/refresh". If you set it to "/", then it becomes "/session/refresh"

fortunately the default value that's being used aligns with what i have

ok, thanks for clearing this all up

the default value of

apiBasePath

is

/auth

. So the default refresh API is

/auth/session/refresh

where can i find details of the default token expiration length?

Morning, I'm not sure if this has been reported, or if anyone else has run into this issue, but in order for my backend to respond to our client, I had to include the following headers in the cors list:

supertokens-sdk-version
supertokens-sdk-name

This was after integrating with superTokens in the front end and modifying the axios instance

any ideas why this might be the case?

I think you are using an older version of the frontend lib perhaps.. we used to send those headers earlier to maintain protocol versioning

If you update to a newer version, those are no longer sent.

I've verified that we are using v5 of the front end SDK

@User we had removed the above two headers from v5 onwards. I'm not sure how it's possible that those are still being sent.. Maybe there is some frontend client of yours that is somehow still using the older version?

the one on my machine right now is v4.3.0, however there are some pending changes that are using v5 my mistake

makes sense 🙂

Asked @User what he recommends for hosting supertokens on in terms of CPU/memory. He said 1 core / 1GB of RAM is enough