Rishabh Poddar

TODO for later (this is out of the scope of the interview trial): We need to do something about `SuperTokensWrapper` as well.

I think the component you want to override is `ThirdPartyEmailPasswordHeader_Override`, and then you can add your own react component there instead of ours.

See a solution here: https://github.com/supertokens/supertokens-auth-react/issues/581 Keeping this issue opened until we add it in our docs.

What you can do is to override the session recipe functions on the frontend like `doesSessionExist` or `getAccessTokenPayloadSecurely` etc to return mocked information if it's testing env. This should solve...

We don't have a specific example for this, but do checkout this: https://supertokens.com/docs/session/advanced-customizations/frontend-functions-override/usage You need to override all the session recipe functions like `doesSessionExist` and return the appropriate values from...

As a follow on to what @RobSchilderr said, we can also offer users the choice of adding different types of auth to their app: - email password - social login...

> NextAuth, Lucia, etc. all provide fairly straightforward ways to customize the providers (email, oauth, etc.) Yup, however, it's just one less friction point for users to get what they...

> in addition to getting the Client ID and secret for their OAuth provider(s) of choice before they can run the dev script and get going. Won't that be true...

Is there interest in adding other auth providers like [SuperTokens](https://supertokens.com)?

In this case, you don't need to use SessionAuth. Just [read the sessionContext](https://supertokens.com/docs/session/common-customizations/sessions/protecting-frontend-routes#optional-session-on-a-route--pre) and check if a session exists using that. Also, this issue is not related to the question...