thanks and sorry for this :D

and then you will have to save those custom fields in your db agains the user ID (Which you can get from the user object)

no worries! happy to help 🙂

its a good lib btw, i am very grateful it exists <3

thank you! :)) Happy to hear this

Hey, I have run into an issue with

req.session

, where it seems like TS does not detect

session

as a property of Request. I did tried to fix it somehow or find answer of what may be causing it, but couldn't find anything helpful. Here I only found one question related to this issue and the answer wasn't really helpful. I'm using Nuxt 2 with Vue and express. If I could get any help with that it would be great.

Hey @KitsuneKenshi you can import SessionRequest type from supertokens-node/framework/express and make the req object of that type.

That would work cause SessionRequest extends Express.Request and adds the session object type to it.

thanks I'll try it in a second

Hello, How can we make multi-domain front-ends work with SuperTokens? In our SPA app, we allow our users to add their own custom domains via CNAME records e.g. planner.domainA.com and planner.domainB.com. This way they can use our app as a white label on their sites for their customers to use. Auth is something we do not offer right now, but we want to add an Auth solution in which they would visit planner.domainA.com/login to login etc. What is the easiest solution to achieve this? Basically, we are looking for a solution similar to Shopify where each user can setup their own shop and auth for each shop. Do we need a multitenancy approach? Supertokens do not support this I can see. Is there a way to make this work with one front-end domain e.g. auth.ourPrimaryDomain.com/domainA for logging in the user and then redirecting them to the custom domain e.g. planner.domainA.com? While keeping the session in the front-end.

So all the domains talk to the same backend api domain? Or do they have different API domains?

Currently its 1 backend api. We just change the logo based on the domain. We want to change it so that each domain has their own orders and catalogues.

We are using Hasura for the backend with Vercel

I see. You can have different domains talking to the same backend.

Essentially, the websiteDomain value on the frontend will be as per that domain

And on the backend, the value of websiteDomain doesn’t matter for this case. You would need to implement a few callbacks on the backend though - to generate the password resent link, and email verification link. In those callbacks, you would get the user as an input. Using that, you can probably know which frontend domain that user belongs to?

I just discovered your product and I didnt have much time to research the technical part. I ll read your docs more and come back with more questions.

My main question was whether you need to have the same domain in the front-end with the backend but it seems thats not required

Any plans to support Vue in the front-end?

So vue support is probably a long way off.. but you can use supertokens-website repo for managing sessions. The rest of the the UI you can make and call yourself and call our APIs

Is integration with Hasura too far away? I can see it on the roadmap

It will be done in 1-2 weeks.

Oh great. About my original question, will I need to implement a reverse proxy as described here? https://github.com/supertokens/supertokens-core/issues/280

Is this the relevant docs with Hasura? https://hasura.io/docs/latest/graphql/core/deployment/enable-https.html

Let me know if there's docs on your site that explain how reverse proxy's work. I dont understand them

You would need a reverse proxy. Yes.

Do you have any other API backend other than hasura?

Only some serverless functions with Vercel

Give me sometime. I’ll reply in a bit 🙂

@User , you would need to host your own backend that integrates with SuperTokens' backend SDK. This backend could be reachable via a sub domain of your frontend. It would expose all the APIs that are provided by supertokens, which your frontend would use. Then there are three methods for auth with Hasura 1) After a user is logged in, you could extract a JWT from the session and pass that to Hasura for auth. Extracting a JWT is still a feature that's work in progress.. It should be avaialbel in 1-2 weeks from now. 2) You could proxy requests to Hasura via your backend API layer which would use our

verifySession

middleware. 3) You could store the user's session ID on the frontend and pass that to Hasura when you query it. Then Hasura can use a custom auth hook to query SuperTokens' core to check if the session ID is valid or not. ---------------------- Out of these, number (2) is the most secure since it doesn't expose any of the session tokens to the frontend (therby preventing token theft via XSS attacks) (1) is the most popular since it's easy to use. ---------------------- Anyhow, you would need to host an API server which would integrate with SuperTokens' backend SDK.