So cookie contains both, then in react native why does cookie get stored and where?

I'm not sure what you mean by why the cookie gets stored - cause if it didn't then, after your app is restarted, the user would be logged out. As to where, both iOS and android provide cookie stores and RN uses those. Those stores are handled by the operating system itself.

Ahhh perfect!, ill be using this solution right now!. Hopefully once I implement it in my back end, you can help me get it to work in RN for my mobile app?

nontheless, Ill be starting tonight. Thank you man! wooo

Awesome! Hopefully the docs for RN will be good enough so that you won't need my help! But anyway, we are always here to help out!

Oh last question, so sorry: Do you guys operate under Apache, AGPL, MIT or No License?

Apache 2.0 license for all the components. Our community core component right now is not that, but we will change it to that soon (you need not worry about it). Our pro version will be a custom SuperTokens license.

And we can use supertokens community forever for free always on Apache? If we find product fantastic we then join supertokens pro?

yup. That is correct!

i mean, the core component (https://github.com/supertokens/supertokens-core), is not apache 2.0 yet. But it will be. The nodeJS lib, the RN lib, all of them are already apache 2.0

but yea, you can use the community version as per your needs for free forever.

You guys will do very well man, no joke. That kind of business is what programmers, companies and users are drawn to.

thank you 🙂

any feedback on how we can improve the installation / usage experience will be quite helpful.

Well, @rp Ill be going through it all tonight, from start to finish. After that. I can write up a small post here with all of the questions/feedback that are my opinions on the current state and what would help if different

sounds good! 👍

Hey SuperTokens, I currently have this middleware that runs on every request

export const secureRoute = async (req: any, _res: any, next: any) => {
  const { authorization } = req.headers;

  if (!authorization) {
    throw new Unauthorized();
  }
  try {
    const token = authorization.replace('Bearer ', '');
    const payload: any = await verifyAccessToken(token);
    if (!payload) {
      throw new Unauthorized();
    }

    req.currentUserId = payload.sub;

    return next();
  } catch (err) {
    throw createHttpError(401, { err });
  }
};

Is there any way to put supertoken session in this or do I not need this any more?

you will need a new middleware. An example of that is given here: https://supertokens.io/docs/nodejs/usage-with-express/verify-session#writing-your-own-session-middleware (if you are using express)

What does one usually store in session data? (as jwtPayload is stored on the session)

So jwtPayload is sent to the frontend. Usually u store the userId and then user role in there. (UserId is already stored there for u). But u should not store anything sensitive

Anything sensitive goes in sessionData. Which is only stored in db.

do you have examples of such sensitive data?

just 1 or so

Uhmm not reallly. But it could be whatever u think is sensitive. Like an email ID. Or phone number or shopping cart information etc..

Generally I would avoid storing much in JWT payload. Just the minimum stuff. Or stuff that’s required for all API calls (like userId or user role)

Ahhh I see

But this is debatable. Cause the JWT is not meant to be accessible on the frontend anyway.. but this is what I am conmfortable with

Yeah I too agree, it's a good balance between risk and making things easier for FE

FE?

front end