though MDN says it's not "strictly deprecated (as in "removed from the Web standards")"

so maybe it's OK to use..

I found something, look at the main question and answers: https://stackoverflow.com/questions/30631927/converting-to-base64-in-javascript-without-deprecated-escape-call/31412163#31412163

Taking them into consideration I believe that we can use escape 🙂

Will make the change and add some tests for this and release the new version.

Great! Thanks

@User , I have released version 7.2.1 of supertokens-website which contains the fix. Please use that

Thanks @User ! I have to adjust all dependencies now because I had to upgrade also supertokens-auth-react package, because without it it didn't work :/

You would just need to delete node modules abs package.json files, and then resin stall node modules. That should fetch the latest version

Unless you are using an older version of supertokens-auth-react. You can tell me which one and I can update the older version of supertokens-website too

I had:

"supertokens-auth-react": "^0.8.0",
   "supertokens-website": "^5.1.0",

And I have upgraded supertokens-website to 7.2.1

Could you update supertokens-website to 7.2.1 inside supertokens-auth-react?

It would be great if I don't have to upgrade it now, because I will be forced to update the backed also 🙂

To sum things up would it work correctly I have on the backend: "supertokens-node": "^4.3.3" and on the frontend : "supertokens-auth-react": "^0.8.0" "supertokens-website": "^7.2.1" ?

@User , i'll make the fix for supertokens-website

5.1.0

. This way, you won't have to upgrade anything and just redownload node modules.

Great! Thank you!

@User , i have updated supertokens-website (new version is

5.1.1

) to include the fix. You should now just have to delete node_modules, remove package-lock.json and reinstall node modules.

Also, the fix is only applied to v5.1.1 and then >= 7.2.1. So in case you want to update to a later version of auth-react, you should keep this in mind.

It works correctly now 🙂 Thank you very much 🙂

Hi. I’m using SuperTokens in my project. Currently I have a NodeJS backend which connects to the SuperTokens auth core (I use session and emaipassword recipes). In addition I have a React app talking with the backend (with custom forms). Now I need to add another frontend react app (other domain). I want to have a group of new users who can only log in to the new app (they should not be able to log in to the current app). Have you got any suggestions how can I handle this situation with supertokens? I was thinking about creating user roles. How could I then add info about which app is the user logging in from? And also is it possible to reject the log in when the user does not have a certain role (without creating a custom endpoint)?

hey @User > I want to have a group of new users who can only log in to the new app (they should not be able to log in to the current app). How are you going to prevent these users from logging into the previous app? By detecting their email used and preventing them from signing up / logging in? > How could I then add info about which app is the user logging in from? You can associate a role to the user once they log in (based on their userID. See this page: https://supertokens.io/docs/emailpassword/common-customizations/user-roles/assigning-users-roles > And also is it possible to reject the log in when the user does not have a certain role Not as of now, but in a few days, we will make a new release that will let you do this very easily 🙂

Out of curiosity... Why do the tokens use custom claim names instead of the well-known/existing claim names? I'm thinking, in particular, of

sub

,

exp

, and

iat

(from RFC 7519) and

sid

(OIDC).

json
{
  "sessionHandle": "0d...",
  "userId": "97d...",
  "refreshTokenHash1": "550...",
  "userData": {},
  "expiryTime": 1623598349546,
  "timeCreated": 1623594749546,
  "lmrt": 1623594749546
}

@seniorquico cause the access token isn’t meant to be used like a typical JWT is meant to be used. A typical JWT is meant to let third party systems be able to verify the contents of the JWTs in a stateless manner. Whereas, our access tokens are strictly meant for session management between your frontend and backend only. No third party system involved.

As such, we merely borrow principles of a JWT (signing and stateless verification). You can think of them as signed payload instead of a typical JWT

An alternate to this would be to use a random string that points to the same payload (in a db). But this would require a db query for each API call.. so to prevent that latency, we used the stateless verification approach.

ok, i get the idea that they should be treated as opaque structures and delegated to SuperTokens for parsing/validation. however, i'm currently looking into using SuperTokens in a C# environment that doesn't yet have an official SDK, and, as such, i'm looking at needing to parse and validate the JWT. there are existing, well-tested libraries that parse and validate JWTs. however, i'm running into problems using them with SuperTokens out of the box. RFC 7519 calls for base64url encoding, but SuperTokens appears to be using the regular base64 encoding. and with respect to the claims, i'll need to recreate all of the validation routines due to the custom claim names. from the RFC: > they provide a starting point for a set of useful, interoperable claims i just find it curious that you decided to explicitly not use RFC 7519 with base64url encoding and the well-known, interoperable claim names.

It was a very conscious decision on our end to not follow the JWT spec here.. cause if we did, we thought it would be very easy for people to misuse the access token as a JWT and send it to third party services (like Hasura which uses JWTs for auth)...

fair enough. thanks for the info!