would you recommend implementing something that prevents the user from having more than e.g. 2 active sessions?

That depends on ur app’s requirement. It’s got very little to do with security.

okay perfect thanks 🙂

What is considered a short lived token? 10 minutes? @User

Yes, 10 minutes would be considered short lived - I'd say anything under an hour. However, its a very subjective thing.

The higher the security need, the shorter the token should be alive for

thanks 🙂

What should happen if I detect token theft (i.e. the refresh token would be used twice)? Should all tokens immediately be blacklisted and, thereby, the user be forced to login again?

i would recommend that you just logout that particular session.

but up to you.

thanks 🙂

I ran into what I think is a bug in supertokens-website /axios. I am setting things up like this

const HTTP = axios.create({
  baseURL: process.env.VUE_APP_API_BASE_URL,
  withCredentials: true,
  xsrfHeaderName: 'anti-csrf',
})
SuperTokensRequest.makeSuper(HTTP)

but SuperTokens seems to not be aware of the baseURL when dealing with a 440 response from the server when a token is expired. I.e., when the session token expires and Supertokens automatically refreshes it, it does a request with the baseURL duplicated, e.g., it tries to access "/api/v2/api/v2/subjects" when the baseURL is set to "/api/v2" and I was trying to make a query to "/subjects".

I see! Alright! Will see this issue. If you could please raise an issue about this on GitHub, that would be great. Thanks

Also, if you are not using version v4+ the SuperTokens-website repo, may I know which version? So that we can fix it for that too. (Since moving from v4+ is a breaking change).

@User we have fixed the bug where the baseURL was being ignored by our package. Please update to version

4.0.12

of the

supertokens-website

package. If you are currently using a version that is lesser than v4, then do let us know which one, so that we can fix that too (since v4 has breaking changes). Instead, if you want to migrate to the latest version of this package, please also make sure that you have updated to the latest backend SDK (because of this issue: https://github.com/supertokens/supertokens-website/issues/6). Also, I'm not sure what led you to have the issue of duplicate

baseURL

. If this is not solved already by our recent update, please provide the following information: - What params are you giving to the

init

function? - A sample API request you are making using your created axios instance Thanks!

@User I was using version 3.2.9 and am switching to 4.0.12 now.

Alright! In that case, please also switch to the latest backend SDK.

@User hi. Did our fix work for you?

We have released react-native support for SuperTokens: https://supertokens.io/docs/react-native/installation @User

> We have released react-native support for SuperTokens: https://supertokens.io/docs/react-native/installation > > @User @User Nice!

Hey @rp if I want to store userType: 'admin' or userType: 'standard' , where should I store these?

JwtPayload

That way, u can get this info on each API request without having to query the db

Give me a min. I’ll send a code snippet here so that things r clear

So when you create a session you can do so in the following way:

let userId = "SomeUserId";
let jwtPayload = {userType: "admin"};
await supertokens.createNewSession(res, userId, jwtPayload);

And in your API you can get this info like this:

let session = await supertokens.getSession(req, res, true);
let userId = session.getUserId();
let userType = session.getJWTPayload().userType

I've got

const payloadData = pluck(user, ['userType', 'isProvider']);
  const jwtPayload = { ...payloadData };
  const sessionData = pluck(user, ['id', 'username', 'email', 'userType', 'isProvider']);
  await createNewSession(res, user.id, jwtPayload, sessionData);

Is that insecure at all?

I am not sure what pluck does