Cool!

yes that sorted out the problem. Might be worth adding a note to the https://supertokens.io/docs/thirdpartyemailpassword/advanced-customizations/react-component-override/usage section to let users know they will need to change the supertokensConfig file extension from js/ts to jsx/tsx before updating the recipe. Also needed to use /** @jsxImportSource @emotion/react / instead of /* @jsx jsx */ in my case.

Thanks for the help @User

@User sounds good. Will incorporate those in the docs soon.

Sweet project 🙂 I'm currently evaluating identity providers for my company. From my due diligence, I got the impression that SSO was implemented but optional in supertokens... but it shows SSO on the roadmap. What is the status of SSO?

Hey @lomz. When you say SSO, do you mean integration with SAML or Open ID connect providers? Or do you mean you want to allow a user to log onto multiple apps (on different domains) via a single login page?

hi, can't we use

websiteDomain: "http://localhost:4000"

? I am getting

Error: Please provide a valid domain name

from

normaliseURLDomainOrThrowError

just wanted to test it locally, not sure if I'm doing something wrong

what version of the sdk are you using?

"supertokens-node": "^6.0.3"

can you show your whole config object?

i mean the init object

the

apiDomain

should be

http://localhost:4000

as well.

you should set the

apiBasePath

to be

/api/

and the same goes for the frontend.

ah my bad

I misread the appinfo documentation

no worries 🙂

mixed the domain and base path 😫

thanks for quick response

fair enough.. maybe we should have better error messages.. hehe

Hey what does "Handshake for session" mean?

It's used to fetch session info like the public signing key. So that the backend SDK can do session verification without calling the core.

So if I am using the core is that irrelevant?

What will be the usecase for it?

> So if I am using the core is that irrelevant? No. The session info is fetched from the core and saved in memory in the backend. > What will be the usecase for it? Once that info is saved, then access token verification can happen within the SDK itself. However, refreshing a session would still require calling the core.

Question: Is Social Login with Apple in the current roadmap? It seems we can't use Supertokens on mobile for auth if Apple is not offered as a social login option. https://developer.apple.com/app-store/review/guidelines/#design (Item 4.8) > Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option.

We already have login with apple @User https://supertokens.io/docs/thirdpartyemailpassword/common-customizations/signup-form/built-in-providers