Is it possible to support multiple website_domains from the same instance?

hey @wonderpandadev No, it is not currently possible to support multiple website domains from the same instance of SuperTokens. The websiteDomain value can only be set to one domain at a time. However, there are workarounds that can be implemented, such as overriding the sendEmail function for email verification/reset password to change the link's domain based on the request's origin. You would also need to set the cookieSameSite value in session.init to

none

(or use header based auth), if the website domains are not sharing the same base domains

They do share the same base domain. That's the main use case we're trying to get working properly right now. So far we've just been using manual sessions and haven't leveraged anything that would include emails. Logging in and leveraging auth from the frontend is working great so far but we have a SAML flow where we need to initialize a session on the server and then redirect to the client and that one doesn't seem to set the cookies properly even though the API and frontends share the same base domain

So you want to share cookies across your sub domains?

Yes, that would be ideal

cookieDomain is for sharing sessions across multiple backend API domains

Oh okay awesome I'll take a look at that and see if it solves my issue

i think so yea. You should ideally initiate a session from an API request from the frontend such that the API request is done with our interceptors in place.

In a SAML flow the response comes to the server first so we can't initiate using an API call from the client

can you elaborate?

When a user logs in using SAML, they're redirected to the Identity Provider to complete the login. The IDP then redirects them back to our server. This is where we want to initialize the Supertokens session as we have access to the necessary information about the user. Our server is a NestJS application and our web-app is a React SPA. In our previous setup before supertokens, we were able to do this inside of the SSOCallback endpoint in NestJS:

response.cookie(REFRESH_TOKEN_COOKIE_NAME, refreshToken, {
      httpOnly: true,
      domain: this.baseHostName,
    });

    response.redirect(redirectUrl);

Now, we're trying to switch over to SuperTokens. I assumed we'd be able to just do

Session.createNewSession

and then still use

response.redirect

but the cookies aren't set this way

> I'm wondering if after the Session is initialized we could get access to the necessary values for the cookies and set them on the response ourselves so that the redirect would work? This is a feature coming soon (in 2-3 weeks). Instead of making your idp redirect the user to the backend, make it redirect to the frontend wherein you send an API call to the backend which creates a session - no redirection needed. If you need redirection, you can do it from the frontend post session creation.

Oh actually... I do see that the headers from SuperTokens are coming back from the redirect.

front-token

,

st-access-token

and

st-refresh-token

are all on the response

right.. ok, so by default we use header based auth if the

st-auth-mode: cookie

header is missing from the request. If you want to enable cookie based auth regardless of this header being there or not, you can provide the

tokenTransferMethod

on the backend's session.init to return

cookie

Okay I'll try hardcoding it to cookie and see if that fixes the redirect issue

cool