Perfect!

But those examples ... still is a little confusing which parts of them apply to me, as someone not using supertokens for auth. For example, yes I'm using

serverless-http

to translate from serverless functions into

(req, res)

style functions, but I'm not using

express

,

body-parser

, or

supertokens.middleware

. Do I need to be using these? Or is the fact that I'm getting these 4 cookies mean everything is okay?

You need to have everything on the backend except for the EmailPassword.init part. And also except for the exactly /sessionInfo API

So you need bodyParser and you need supertokens.middleware

And you also need the supertokens.errorHandler

Is there some way to test out that my current setup is not working correctly due to the absence of those two things? What "should" be broken, as a result of not using

bodyParser

or

supertokens.middleware

?

So if you delete the sAccessToken from the browser, and make an API request to a route that requires a session, that will fail with a 401, the SDK will try and call the refresh API which will return 404. Since you don’t have supertokens.middleware

Once you add that and bodyParser, then the refresh call will yield a 200 and not 404. And the frontend SDK should then again call the original API which should then return 200 since a new sAccessToken is available

Gotcha. Okay I will try it out

Is there a reason the user's faunadb Ref# is exposed on the frontend? Seems like an unnecessary thing to have there, when all I need is the (short-lived) faunadb token

That ref is the userId associated with the session. For several apps, they require a user’s ID on the frontend so we provided that feature. Is it a security issue for your use case @thisjust ?

Hi @User, I don't need it, since FaunaDB infers that info from the token. Not a security issue per se that I can think of, just seems like a good practice to not expose internal db info when it's not needed. If there were a supertokens config setting or something to easily keep that info out of the frontend, I would make use of it, but I don't think it's a big deal

Cool. Let me see what I can do about this. If there is a quick config I can add.

Okay thanks! To change the subject: to log a user out, it looks like I need to implement a "/logout" route on the backend, yes? Or is there something I can call on the frontend that already accomplishes this?

As far as implementing "/logout", I found this: https://supertokens.io/docs/thirdpartyemailpassword/common-customizations/sessions/revoke-session

You would need to implement this on the backend. Any API that verifies a session, and then calls revokeSession in the API

Yea. That link is correct. You should follow the method using the req object.

Are there pros/cons to

The req object one is the only method that clears the tokens from the frontend + the db. The other ones only clear from the db.

let sessionHandle = req.body.sessionHandle
await Session.revokeSession(sessionHandle);

vs verifying session with middleware and then``` await req.session.revokeSession(); ```

I think I’ll change the docs to make it more clear as to which method to use for signout API vs other ways and their use case.

Okay cool, this one, yes?

await req.session.revokeSession();

Yes.

And on ur frontend, when you call this API, you should check if the status code is 401 (or 200). Either of them means that sign out was successful

Since if ur getting 401, it means the session has expired (which is equivalent to a sign out)

Okay I will check for that on the front end.

Hmm I'm getting

supertokens.verifySession is not a function

Okay I figured out it should be

Session.verifySession

, from searching your repo for

verifySession

. But your docs say to use

supertokens.verifySession

Oh! Thanks for pointing that out. Will fix it @thisjust