https://supertokens.com/
Join Discord
<@498057949541826571> Is there any configuration required on the server-side (during self-hosting) t...
# support-questions-legacy
e
@rp_st Is there any configuration required on the server-side (during self-hosting) that's needed for the multi-tenancy (one login per sub domain)? Right now we're experiencing a bug where logout doesn't actually logout as when i login in sub domain A and then attempt to logout in sub domain B the cookies are not removed and it stays forever in a loop
r
hey @enigma_666
do both the sub domains initialise the supertokens frontend SDK?
e
Yes
They are 2 individual react applications
r
whats the session.init setting on both of them?
e
The info is pretty much the same for both, we initialize the session recipe (no options passed) and for the appInfo we're only providing appName (distinct) and the same api domain and path
The session init is an empty object, there's nothing we're providing there
r
right. So you want it that if the user logs into one of the sub domains, that session is only specific to that sub domain?
e
It can be linked
All i'm saying is that by default it goes into a loop because when domain A has logged in but logged B shares the same session and tries to logout he'll get an error
r
do they both query the same apiDomain?
e
yes they do
r
right. So that's why
you should switch to using header based auth in this case
since the session tokens are attached to the apiDomain
so logging out of one will clear those
but the frontend's state on the other one will still say that a session exists.
but, when that does a refresh, it should logout the user of that too - is that not happening?
e
If at the domain A i sign in and then sign out, it works
It's just when you mix both, when you sign in at one page but start working in the other
r
oh yea.. i understand that
e
Because at that point, we assumed that the cookies not being set from the response were being flaged with some domain mismatch
Yes it should logout* but that never happens, it treats as if both had invididual refresh tokens and one will have its own to refresh which was weird but that's just a wild guess
It will eventually refresh and so it keeps there forever
r
so the infinite loop only happens if you call the sign out API from the other domain right?
e
right
calling from the other domain, the response never sets the cookies
r
if any other API returns a 401, it should call the refresh, which will clear the frontend tokens correcting the state?
e
correct
r
ok. So this is an issue with the sign out API returning a 200 as opposed to a 401 even though the cookies are missing
makes sense.
can you open an issue about this on our github? In the meantime, you could switch to using header based auth (which will not clear tokens across sub domains on logout), or you could share the same session acorss the two domains.
e
We want to share the same session on both domains
What would be the workaround that you recommend? Yes i'll open the GH issue and try to add as much repro/context as possible
r
i would recommend that you share the same session across both the sub domains: https://supertokens.com/docs/session/common-customizations/sessions/share-sessions-across-sub-domains
e
That's it, basically nothing goes in the request cookies/headers and the server returns a 200 and so the resopnse cookies get filtered out
Oh i see, i didn't realize about this option. Thank you! I'll try and let you know
In this field it should be the base domain right?
r
yes
with a leading 
.
on both the sub domains
e
thanks man, i appreciate the time!
I'll let you know on the findings once i apply this.
@rp_st just getting back at you: it worked 😎
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