Hi, when I initialise supertokens on the server si...
# support-questions
b
Hi, when I initialise supertokens on the server side, I always pass an appName as well. Is it possible to have a core instance of supertokens that distinguishes users by appName? So that, for example, 2 projects exist and 1 supertokens core. The two projects both initialise supertokens in the BackEnd with 2 different app names. If the user with the email foo@bar.de logs in to project 1, he is not automatically logged in to project 2. Is this possible? Thank you for your work
r
hey @beagle
Do you want to share the same user pool across both the apps?
b
hey @rp yes 🙂
r
i see. So it's only about not sharing sessions?
b
yes, I would say
r
and what are your api domains for these two apps?
b
they differ in the subdomain foo.bar.com and other.bar.com
r
I see. So the session should be different anyway. In one app, the session will be attached to
foo.bar.com
, and in the other one, it will be attached to
other.bar.com
. Have you changed the config to share a session across sub domains?
b
No, not yet, but I think it goes beyond sharing the session (sorry for the wrong answer above). What I mean is that the user can log in to foo.bar.com and I can set the session for other.bar.com so that it is no longer shareable. But it would still be possible for the user to log in to other.bar.com with their credentials without having to re-register. I would like to prevent this, i.e. that the user has to register again for both domains.
r
ah right. So for that, you have two options: - Use two different cores - one for each app (recommended approach) - Modify the signUp / signIn functions of the recipe (on the backend), to append a
+appName
to the email ID being used to sign in / sign up. For example, if you the user uses
a@example.com
to sign up on
app1
, their effective email that you send to supertokens would be
a+app1@example.com
.
b
ok thanks for the answer, then I will go the recommended way...would such a distinction based on the appName make sense in the future, or would that lead to more problems than it would solve? 🙂