https://supertokens.com/
Join Discord
Hi <@498057949541826571>, I need to have access to one self-hosted supertokens app from multidomains...
# support-questions-legacy
i
Hi @rp_st, I need to have access to one self-hosted supertokens app from multidomains.I mean that I want to use one app for authorization in different sites with similar sub-domain of second level. Are there any options to do that(maybe i can put mask of website domain to app config like .example. or something like that)?
r
Do you mean that you want to share a user's session across sub domain?
i
I mean that I have one api for supertokens authorization, and now one frontend with domain stage.example.com use my api. To do that I put website domain to supertokens app config at backend. So, I want backend app can be usable for many frontend domains, but with same subdomain(.example., like prod. example.com, prod.example.ru, my.example.dev.ru etc.)
r
Right. So you can put the websiteDomain value there to 
prod.example.com
and it should work fine for prod. Email verification links / password reset links will point to prod.example.com as well in this case, so they may not work as expected in dev and staging envs.. But you can override the emailDelivery config to change the generated links before sending them in the email.
i
can i put mask like '*.example.*' or array of domains to websiteDomain variable?
r
Not yet.. We are working on an update that will allow that.
For now, im afraid, this is the only option.
i
okkk....
(
r
yeaa.. we are aware. It can be a pain
Thats why we are working on changing it so that you can give an array or a function to it to allow several combinations of clients etc..
i
and about sharing sessions with multiple subdomains
I see now example of this
And I cant clearly understand whats going on
r
which example are you referring to?
i
r
Have a look at this:
i
hmm, is there mean, that if I get request from auth.example.com it wil give me a session from example.com?
r
yes
i
okey, and can i put there '.example.'? will it work for test.example.ru sharing with test.example.com for example?
r
No. Cause one ends with .ru and the other with .com.
So the two domains you mentioned are not sub domains
i
okey, now its clear, thank you very much for help)
and last question, should i add whitelist from this example(https://github.com/supertokens/supertokens-auth-react/blob/master/examples/with-one-login-many-subdomains/api-server.js) to cors for solution you have suggested?
r
Yea i mean the cors should be setup in a way that allows you to query whichever domain you are expecting to be queried from.
i
ok, its like feature bc now i set option origin: true
Thank you again)
To continue discussion with no creating new and same, I have a question: can I put regular expression to session scope by default behavior? If no, how can i improve core or SDK for myself to implement this, can you give me any variants as advice?
r
You can't add a regular expression for this at the moment. What are the values that you want to support for sessionScope? Do they all have the same base domain?
i
I want to support '.test.com', '.test.ru', '.test.dev' by the way, that I want to have one session for first and second
for example
r
hmmm. I see. So even if you are able to set the sessionScope via a regex for these, the browser will not allow this behaviour.
So there is just no way of sharing the same session across these domains since their base domain is different.
So you will have to implement some work around
i
Ok, have you got any idea, how can I do this? maybe some advice, I mean
r
So which site from the above list has the sign in page? Can the user sign in from any of the domains or just one of them?
i
From any
r
right. And if they login from any one, they should be logged into all of them?
i
Yes
r
hmm
So the best way to solve this is to do the following: - Create a dedicated sub domain like auth.test.com which is responsible for login. That sub domain uses supertokens on the frontend + backend to make the auth UI. - If the user visits .test.com site or test.ru site, then you check there if a session exists, if not, you redirect the user to auth.test.com. - Once the user is on auth.test.com, you ask them to login if a session doesn't already exist. - Once they have logged in there (or if a session already existed), you can redirect the user back to where they had initially visited with a JWT or something. - The original site gets back a JWT and then can consume that to create it's own session on that site.
I'll think about if there is an easier way..
i
Okay, thank you
r
yea it is about sharing sessions. The first link is for sharing sessions across frontend sub domains, and the second one is about sharing across API domains (that the frontend can call)
i
hmm...and whats a difference, can you give example as explanation?
r
so if you have frontend website on a.example.com, and b.example.com and want to share a session across those, then the first link is useful
and if you have multiple API domains (that are being queried by your frontend), like a.api.example.com or b.api.example.com.. and you want to share session across those, the second link is useful
so for frontend sharing, you can make it so that the user logs into auth.example.com and then even example.com or a.example.com know about the session
i
Use second link for this? or still first?
r
first
i
ok
Now its clear
PreviousNext
Powered by

SuperTokens.com

SuperTokens is an open source authentication solution offering features like: Different types of login: Email / password, Passwordless (OTP or Magic link based).

Powered by