And how do you to the login / session creation operation?

Currently relying on default route for signin. I have a function using axios to sign in at the moment, ``export async function signin(email: string, password: string): Promise { const body = { formFields: [ { id: 'email', value: email }, { id: 'password', value: password } ] } let response try { response = await axios.post('auth/signin', body) const userId = await SuperTokens.getUserId() store.commit('updateUserId', userId) console.log(await SuperTokens.doesSessionExist()) } catch (e) { console.log(e) } return response }``

Ok and then callling doesSessionExist return a true?

Yes, it does

What’s strange is that the browser isn’t even adding cookies to the graphql request

Sure

Or even better, make the request using fetch

I am still getting unauthorized. Looks like my cookies are not set properly. As checking for session right before sending the requests is returning false.

Hmmm. When the cookies are returned from the login API, do you see any warning printed on the console?

Nope, not any warnings. Do I have manually set sAccessToken in the cookies?

You don’t have manually set them

sFrontEnd is enough?

How about the set-cookie header from the login response, do you see a small orange triangle at the end of the header line?

SamSite="Lax" is has blocked it because due to cross site response

What’s your frontend domain?

It was set to localhost:8080. I just set it to http://plizz.mycorpsec.test

So you want to set it to the same value as what you are testing this on

Is it possible to set websiteDomain as regex to handle multiple domains?

Not at the moment

Ohh, I am trying to make proof of concept for multi tenant app. And people can register own sub domains. I wanted an single api to handle all sub domains request.

So if it’s sub domain, that works too. Set the websiteDomain on the backend to be equal to your top level domain

I am only running it locally at the moment.

So if your frontend is loading on localhost:8080, you should set the websiteDomain on the backend as localhost:8080

Ohh, I am sorry. yeah, it was set to localhost:8080. Lax prevented it.

Right.

Is there a work around for this at the moment?

just set the websiteDomaon on the backend to what you are testing with

SameSite="None" also blocks it because it is not secure

Ah. So then you have to make it https. There is no choice around that unfortunately. It’s a browser rule

Right now I have sameSite to None, cookies sercure to true

ok awesome!

Thanks for the help @User !!!!

So now in the case of the testing and prod multi tenancy env, would this same setup work? Or is that still unknown?

Still unknown. Looks like we might have issue when user logins with different sub domains in the same browser.

So we do support logging in via multiple sub domains

I see. We do not want to share any session.

I see. So what you will want to do is: - On the frontend, the value of websiteDomain should be the current domain

window.location.origin

- On the backend, you can set the websiteDomain as your top level domain for the website. - On the backend, you want to provide some callbacks to return the right sub domain for the user for things like creating a password reset link or email verification link. I can give you a list of which callbacks to provide if you tell me which recipe(s) you are using on the backend.

EmailPassword

You want to provide the

resetPasswordUsingTokenFeature.getResetPasswordURL

function: https://supertokens.com/docs/emailpassword/common-customizations/reset-password/embed-in-page#step-3-changing-the-website-path-for-reset-password-ui-optional And you want to provide the

emailVerificationFeature.getEmailVerificationURL

function: https://supertokens.com/docs/emailpassword/common-customizations/email-verification/embed-in-page#step-a-on-the-backend In both these functions, you will want to fetch the right sub domain for the user and return the URL with the correct sub domain for that user.

Alright, I will look into these. Thanks for all the help.

No. I meant websiteDomain. Cookie domain would be used if you want to share the same session across sub domains - but you don't want to do that.

Ohh, I am not sure where I would set websiteDomain? Currently, cookies are being set on all the sub domains in the browser. I have not set any cookieDomain in backend or frontened.a

Oh yea. You are using the supertokens-website SDK which doesn't have websiteDomain. So ignore that comment then.

Is there a way to disable cookie sharing?

by default, the cookies are not shared across sub domains

I see. Currently I have abc.example.com on one tab and xyz.example.com on the other, when I login in first one, I see sAccessToken and refreshtoken set on the second one too

Yes. You would see those as the tokens are attached to the API domain, and not the website domain. But if you query

doesSessionExist

on

xyz.example.com

, it will return false. If you make an API call from

xyz.example.com

(to the same API domain as the one you query to from

abc.example.com

, the cookies will go in the API, but then you can solve this issue by: - During session creation, add the sub domain in the access token payload - Post session verification, check that the sub domain in the access token payload is equal to the origin in the request. If it's not, reject the request (send a 401). This way, you can restrict the session to be in just one sub domain, even though the different sub domains query the same API domain.

Okay. But does it mean I can still use multiple accounts in multiple domains in the same browser at the same time, like switch back and forth without signing out? I am bit confused.

hmm. So you won't be able to do that. Unless the API domain for each sub domain is also different.

Okay

is that a blocker for you? Im curious about your use case now.. haha

One of those extreme cases where our users can work across multiple tenants.

hahah.. well... One solution for this would be to in fact share a session across sub domains, and if the user tries to access another sub domain than the one they logged in with, you can detect it's not the right sub domain and redirect them to the right one. Or, show a message saying that if you want to login to this concurrently, please use a different browser or a private window. Perhaps this could be a clean solution and a good UX.

Well, I will suggest this to my team. 😅

The session would work exactly the same way with supertokens-auth-react

Alright. Thank you!