Hi, I have a question. We currently use Web3Auth but think about exchanging it as we really do not need the Web3 actually anymore 😁 But what is awesome about Web3auth is that it actually allows you to use social logins without leaving the page. You can just configure to open the login in a new tab, authenticate the app and the tab closes again. The widget talks to the backend and shows a login success. Is this kind of flow possible with supertokens? Here is a demo: https://demo-app.web3auth.io/

hey @bitwiz you can do socail login via a popup instead of a page redirect.

Hi @rp_st thank you for your answer! I will try that out! How tricky is this in general to setup? I am quite good with general web dev but not necessarily with auth flows. Do I get back the details of the logged-in user from the backend then? The nice thing with Web3auth was that it was super easy to set up and you get back a fully populated user object with name, email etc if provided by the social provider.

You do get back the access token from the social provider on the backend using which you can fetch any info about the user.

Hi, sorry I do not get it. The example says I should overwrite the button todo something else. But in the React demo app I am not able to modify the component or access the button. There is just "{getSuperTokensRoutesForReactRouterDom(require("react-router-dom"))}" That should get the login modal? I do not see how I can manipulate this :/

Checkout the react component override feature in our docs

Will do thanks!

hey! are you using our dev credentials for social login? You should instead use your own credentials and on the provider's dashboard, set the redirect_uri to point to your app's callback screen

This is basically the only thing I changed: I have not entered any credentials so far

<ThirdpartyPasswordlessComponentsOverrideProvider
        components={{
          // In this case, the <ThirdPartyPasswordlessHeader_Override>
          // will render the original component
          // wrapped in a div with an octocat picture above it.

          ThirdPartyPasswordlessHeader_Override: ({ DefaultComponent, ...props }) => {
            return (
              <div>
                <img src={"https://avatars.githubusercontent.com/u/583231"} height={50} />
                <DefaultComponent {...props} />
              </div>
            );
          },
          ThirdPartySignInAndUpProvidersForm_Override: ({ DefaultComponent, ...props }) => {
            console.log("props", props);
            const url = getThirdPartyAuthorisationURLWithQueryParamsAndSetState({
              providerId: "github",
            });
            console.log("url", url);

            return (
              <div>
                <button onClick={async () => window.open(await url)}>Hamlo</button>
                <DefaultComponent {...props} />
              </div>
            );
          },
        }}
      >

no i mean on the backend. What credentials are you using?

Ah I see: You mean those:

ThirdPartyPasswordless.Google({
                    clientId: "1060725074195-kmeum4crr01uirfl2op9kd5acmi9jutn.apps.googleusercontent.com",
                    clientSecret: "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",
                }),
                ThirdPartyPasswordless.Github({
                    clientSecret: "e97051221f4b6426e8fe8d51486396703012f5bd",
                    clientId: "467101b197249757c71f",
                }),
                ThirdPartyPasswordless.Apple({
                    clientId: "4398792-io.supertokens.example.service",
                    clientSecret: {
                        keyId: "7M48Y4RYDL",
                        privateKey:
                            "-----BEGIN PRIVATE KEY-----\nMIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgu8gXs+XYkqXD6Ala9Sf/iJXzhbwcoG5dMh1OonpdJUmgCgYIKoZIzj0DAQehRANCAASfrvlFbFCYqn3I2zeknYXLwtH30JuOKestDbSfZYxZNMqhF/OzdZFTV0zc5u5s3eN+oCWbnvl0hM+9IW0UlkdA\n-----END PRIVATE KEY-----",
                        teamId: "YWQCXGJRJL",
                    },
                }),

??? I changed nothing there

yup

Ah I see.

Hmm. I see. I'll have to check and get back to you on Monday. Perhaps @sattvikc can help here.

Thank you so much! If you need to understand the setup better: https://shopify.dev/docs/apps/online-store/theme-app-extensions. With shopify extensions you basically bundle your app and inject into Liquid, shopifys templating language. The result is called an "app block". This gets integrated into the shop of a merchant that installed the app. The downside is you really just control the scope of your app and not the routes.

we shall get back to you on monday

But in general I can only recommend you guys to have a look at the web3auth flow. It is just super convenient. There could be a business opportunity for you guys 🙂

we do plan on adding web3 auth next year!

You mean auth with ethereum or really the product of the companny web3auth?

im not sure at the moment

Because I talk about the product of the company 🙂 https://web3auth.io/

i see.

All of the social auth providers work without me doing anything. As I said. business opportunity for you guys. I never saw that so easily solved. But we do not need the wallet part anymore. I leave you to it then. Thanks for your help so far ❤️

Thanks. We will get back to you on Monday 🙂

hi @bitwiz , we have added an example for login using pop-up. Please check if this helps - https://github.com/supertokens/supertokens-auth-react/tree/0.31/examples/with-thirdparty-popup

Guys this is AWESOME!! This is the best support I have ever experienced ❤️ Thank you so much!! Can you explain a little bit what you have done? I see the ThirdPartySignInAndUpProvidersForm_Override and that you wait for the close event of the popup. That makes sense. But how is the close event triggered in the popup? Can you give a bit of context? Does it have todo with the

authorisationURL: `${getWebsiteDomain()}/auth/callback/${provider.id}`}

Or did you change something in the backend or on your callback page? Thank you again so much!

When the above callback page is loaded (which is a frontend route), we consume the auth token and then close the popup

Just found the line of code myself 😄 So this part is actually executed on the callback page?? This is super smart!

Yup. It is executed by the callback page indeed.

Still learning your framework but now it starts to make sense. super smart. That will definitely help. One last question: If I want to get my own Oauth keys for production use I have to use my core connectionURI?

Well, those are two different things. The core connection is to connect to the core which interacts with the db in which ST related info is saved. Whereas the social login credentials (oauth keys) are provided by the social login provider for the purpose of talking to the provider (which is different from the core)

Okay now I am confused 😄 Let me elaborate:

yes

Sorry hit enter accidentally. Will edit it

no. That happens on your frontend.

Ifames are possible but discouraged. The app is bundled via webpack and uploaded to shopify. They embed the app in the store frontend when a merchant installs the app. Your code is basically injected via src tag into the shop. So I could use an Iframe there but as thats super tricky with responsiveness. This app Is where I want to render the login buttons. We actually just want to build an app that makes it more easy for merchants to get people to signup to their newsletter via social logins. But thats it. We cannot control routes on the shop.

i don't think you can do cross domain window events listening. There are ways to get this to work, but will require a bit of work: - On the shopify app, you can open a popup window to go to google like you are doing now. - Google redirects the user back to your statically hosted site which will call the signinup function to your backend. This will also create a supertokens session between that statically hosted site and your backend. However, the above won't create a session between your shopify app and your backend, which is what you want. In order to do that, you will need to somehow transfer the session from your static site to the shopify app dynamically. I can think of one way of doing this: - When the shopify app opens the popup for google, the URL that is opened contains a

state

query param which our SDK generates. You can save this

state

param in the shopify app (in memory) before opening the popup window. - When google sends the user back to the callback page on your static app, this same state param is also present in the callback URL. You can save this state param in localstorage of your static site. So at this point, you have a common state param stored in your shopify app (in memory) and the static site. - After the static site is logged in (after it has a session with the backend), it could send the stored state param to your backend. On the backend, you create an API which accepts this state param along with verifying the session. - Post session verification, this API has the userId and the state param. It can store this mapping in memory. - Meanwhile the shopify app can poll the backend with the state param, and if that API sees that there is a mapping of this state param to a userID, it can simply create a new (header based / non cookie based) session and return a 200 to the frontend - thereby logging in the user.

That is actually exactly how I thought I have to do it before I thought that your connection URI would also be the callback domain 😄 That makes absolute sense and should not be to hard I guess!!

great! :))