ok, i will try this and come back with more question when i get to that portion of work in the solution

Sure. I may also have a few questions to better understand your use case so that I can guide you better. As session management is a very important part of any app.

no problem, send me a DM if you have any project specific questions

Sure.

i noticed that the demo has 3 tables but the documentation says that the library will create two tables

was the 'all_tokens' table specific to the demo?

also, is there any documentation describing what algorithms are used for the request_tokens, and keys used to sign the access_tokens?

@tredstone , to answer your first question: The latest release on npm is 4.3.0, which requires just two tables. The master branch on the github repo is on version 5.0.0 which is not release yet and is being used by the demo website. That's why there is a difference in the number of tables. However, you can still see the demo website code for implementation reference.

to answer your second question: I assume you mean refresh_tokens and not request_tokens. There is no documentation for this part. If you are interested, i'd be happy to point out to you, the code section for this.

Code to generate a new signing key (to sign access tokens): [function at line 17]: https://github.com/supertokens/supertokens-node-mysql-ref-jwt/blob/v4.3.0/lib/ts/helpers/utils.ts Code to create and verify JWT access token given a signing key and JWT payload: https://github.com/supertokens/supertokens-node-mysql-ref-jwt/blob/v4.3.0/lib/ts/helpers/jwt.ts Code to encrypt and decrypt refresh tokens: [function at line 52 and line 92]: https://github.com/supertokens/supertokens-node-mysql-ref-jwt/blob/v4.3.0/lib/ts/helpers/utils.ts I hope this helps.

thank you

Hi again, i was looking at the documentation for the SuperToken config, and i have a question about this: // get: undefined, // is a function of type: () => Promise // } This is for the 'accessToken' section of the config. is 'get' asking for a function that returns a promise that resolves a string?

I'm missing a post here.

Deleted?

A notif wouldve been nice; time went into making it.

i was looking at this page: https://supertokens.github.io/supertokens-node-mysql-ref-jwt/docs/backend/usage-with-express/initialisation and going through the optional parameters for the 'accessToken' portion of the config

Is there info about why the demo only works on Mozilla Desktop? What is the limitation

Good question, hopefully its a very front end specific implementation for their example

could be a browser nuance they only have with FF

@tredstone yes, get is a function that returns a promise that resolves to a string. The string is the custom JWT signing key.

The reason why the demo works only for Mozilla is because copying cookies to emulate an attacker is simplest on Mozilla. On chrome and other browsers, you can’t see the refresh token cookie unless you load the refresh token path in the URL. Which for demo purposes is difficult to communicate. There is no inherent limitation and the solution works the same on all browsers.

@Everybody apologies for deleting your post. I thought it was a bot post. Oops! 😅

Also, @tredstone, get is an optional parameter which is undefined by default. So, if you don’t pass it, the signing key is generated and maintained by the library

I'm attempting to work out a solution to hosting a public facing encrypted database on .git which tiers access to users DHT web torrent style multi-client solutions under consideration.

@Everybody I see. I’m not too sure I completely understand what you mean, but I’m happy to help out if you have any specific question 🙂

is there a reason the accessToken and refreshTokens are attaches to the response as cookies?

as opposed to sending them in the response body and attaching the access token as an Authorization header

with the current implementation, aren't the access token and refresh token sent with every request?

So the recommended way to store the two tokens is via cookies (as opposed to local storage) as it provides security against XSS attacks.

The refresh token’s cookie path is only specific to your refresh token API