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

Oh, I didn't find in the doc I was looking at. My bad! Thanks

No problem! Which doc were you looking at btw? Perhaps those docs need updating..

Right on the start: https://supertokens.io/docs/thirdpartyemailpassword/quick-setup/frontend

It seems there is missing info in the guide for Apple as well, for example: what is the Return URL for supertokens for Apple ID?

@User can help with that

Hi @User, callback URL for apple would be

{websiteDomain}/auth/callback/apple

. In general, callback url is

{websiteDomain}{websiteBasePath}/callback/{id}

where

id

is the unique id for the auth provider, and

websiteBasePath

by default is

/auth

thx!

Sorry for the delay @rp. I am still new to the auth provider world, thank you for the clarifying question... I meant logging into multiple apps. I guess my question is around supertokens being the SAML/Oauth provider. My use case is: User logs into my app using supertokens, and then is able to log into another app and be identified using supertokens. Not sure if I'm even looking for the right thing 🙂

Understood. Does the other app share the same base domain as the place where the user is going to login from? For example,

auth.example.com

logs the user into

a.example.com

or

b.example.com

.. versus,

auth.example.com

logs them into

someotherdomain.com

.

>

auth.example.com

logs them into

someotherdomain.com

. this is my primary use case

Ah ok. Unfortunately, we don't support that at the moment. However, you could use us for auth in

auth.example.com

, and then use some other solution like ORY Hydra to make

auth.example.com

into an OAuth provider and connect that with

someotherdomain.com

, and then, in

someotherdomain.com

, you could use us for sessions as well.

Great resource. Thank you @rp!

Hi, I'm trying to figure out if it's possible to export users from the hosted SuperTokens product?

@User , there are three ways: - You can download the csv file. - You can loop through all users (via pagination functions we provide in the SDK), and get their info and then insert them into your db. - We can give you a postgresql db backup snapshot.

Thanks for the quick reply! So that means, if need be, there is a way to migrate from hosted SuperTokens to self-hosted or a different solution without having to ask users for password resets/reauthentication with social providers?

yup. However, if you want to move to a different solution, ti depends a lot on how they work as well.

Cheers! I just have to tick a check box that it's possible.

See https://supertokens.io/docs/community/migration/to-st -> approx the same way would work for away from st.

why does EmailPasswordAuth trigger always twice the verify route?

What do you mean by verify route? I don't think I understand your question @User

when I use EmailPasswordAuth component in react, it triggers twice the /auth/user/email/verify route.

Could it be you're just seeing the

OPTIONS

request as well?

nope it's twice a get

I also removed the Component and the request did not happen anymore, so it's the only occurence

Are you updating the state in the

componentDidMount

or anything like that, to cause re-renders?