For the rest of the app, continue to use angular with supertokens-website SDK

thank you very much for your time and for giving the hints I needed

Happy to help 🙂

Hi, supertokens shows on the first view nice. But i have a few question. 1. My ui/ux guy will a registration form with just the email and after validation, shows a another form with set password and after that the basic form with name etc.. will this basic infos stored in supertokens db or need i a seperate? 2. Currently i use Keycloak with a lot of realms, if i use supertokens. Need i for every realm a server or can i use one server? 3. Can i check if a user is login or not without redirect? 4. Can i map providers like ldap for groups, permission and user info to supertokens db or need a seperate db? 5. I nothing found if it possible the credential, privancy police change / update the user need to accept it before using the service? In keycloak a flow exist for this case, also here?

what does verifySession do?

@User 1. The basic info will need to be stored in your db 2. You would need a different supertokens core + backend API per realm. We don't have multi tenancy support yet. 3. Yes, you can. 4. Separate db. We don't have authorisation yet. 5. You can make this as a customisation on our React UI that we provide.

@User It verifies the session. It expects the

sAccessToken

and

sIdRefreshToken

cookies in the request and attempts to use those to verify the session. If successful, it creates a

session

object inside the

req

object which can be used in your API to get user info and / or manipulate the session.

Using Apollo GraphQL + NestJS, apollo expects to send the response itself. When using verifySession I see that verifySession sends the response and then apollo graphql throws an exception that headers were already sent. How should I setup supertokens with nest+graphql?

Are you using the session verification guard in nest JS as explained in the docs? https://supertokens.com/docs/thirdpartyemailpassword/nestjs/guide#7-add-session-verification-guard

Yes

So that would throw an error in case of a session refresh is needed. The error should then go straight to the error handling logic here: https://supertokens.com/docs/thirdpartyemailpassword/nestjs/guide#6-add-the-supertokens-error-handler I wonder why it would call the graphql part at all in this case..

do you know why?

I have no clue yet. I guess apollo transforms the exception 🤷

hmm. I don't think it would. Cause otherwise the supertokens error handler would probably not be able to catch it, in which case it wouldn't send a response, in which case you won't see the headers sent error.. but im not sure. How have you added graphql to the nest app?

Sure, we had it working before...

Without supertokens

Also, it works properly when the session doesnt need a refresh

Can you show me how you are using graphql + supertokens + nest js?

In Nest documentation, https://docs.nestjs.com/graphql/other-features, they say:

Note that unlike the REST case, you don't use the native response object to generate a response.

like the place where you are calling verifySession

So I think I might know what the problem is

when the verifySession needs to refresh the session, it throws an error. Does that error get caught by this handler? https://supertokens.com/docs/thirdpartyemailpassword/nestjs/guide#6-add-the-supertokens-error-handler

You can check by console logging in that error handler

Already checked. It does. The headers are already sent there so it returns.

So that's expected.

They get set in verifySession

So after the SuperTokens error handler returns, where does the execution go next? In the graphql exception handler? or somewhere else?

In the case of an express implementation of the backend with supertokens, would an unsuccessful verifySession() go to the next middleware handler or would it end the request response cycle?

It would end the req / resp cycle. But you can use

verifySession({sessionRequired: false})

to make it call the next middleware even if a session doesn't exist. In this case,

req.session

will be

undefined

.

It seems like the exception continue to the graphql that generates a graphql error out of it, builds a response and tries sending it