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

hey @beagle0561

hey @rp_st yes 🙂

i see. So it's only about not sharing sessions?

yes, I would say

and what are your api domains for these two apps?

they differ in the subdomain foo.bar.com and other.bar.com

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?

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.

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

.

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? 🙂