https://supertokens.com/
Join Discord
hey <@!909850506992685157> , which supertokens recipe are you using? And I assume that your API is ...
# support-questions-legacy
r
hey @User , which supertokens recipe are you using? And I assume that your API is = websiteDomain + some path?
@User let's talk in this thread.
m
Hi!
We're using emailpassword and session recipes
Copy code
supertokens.init({
    framework: "express",
    supertokens: {
        // These are the connection details of the app you created on supertokens.com
        connectionURI: process.env.SUPERTOKENS_URL,
        apiKey: process.env.SUPERTOKENS_API_KEY,
    },
    appInfo: {
        // learn more about this on https://supertokens.com/docs/session/appinfo
        appName: "Serif Health",
        apiDomain: process.env.BACKEND_URL,
        websiteDomain: process.env.FRONTEND_URL,
        apiBasePath: "/auth",
        websiteBasePath: "/",
    },
    recipeList: [
        EmailPassword.init(), // initializes signin / sign up features
        Session.init() // initializes session features
    ]
});
It's fully working in production and in local dev
so no issues there, it's just these vercel preview deploys that get random subdomains off *.vercel.app
r
And are both 
BACKEND_URL
and 
FRONTEND_URL
*.vercel.app in that case?
m
Not yet - I was curious if we can allow for an array in FRONTEND_URL - so both preview and production deploys can talk to the same API instance
(assumption being the preview deploys for production should still talk to production APIs and database)
r
This kind of situation requires multi-tenancy support which we don't have at the moment. One way to solve this is to spin up a different backend process which will only be queried by .vercel.app env, and so it's settings will have the websiteDomain as 
serifhealth.vercel.app
. If you want to have just one process though, it's a little messy, but possible. The purpose of 
websiteDomain
is to generate reset password links and email verification links + determine the settings for cookies. So you can emulate multiple values for this by providing callbacks for generating a reset password link (with a different link) and an email verification link (with a different link) + setting cookie settings manually (you can keep the 
websiteDomain
to serifhealth.com in this case). 1) generating a password reset link: Provide the 
getResetPasswordURL
URL as shown here: https://supertokens.com/docs/thirdpartyemailpassword/common-customizations/reset-password/embed-in-page#step-a-on-the-backend to generate a link for *.vercel.app in case the request is from the staging env. 2) generating an email verification link: Provide the 
getEmailVerificationURL
URL as shown below: https://supertokens.com/docs/thirdpartyemailpassword/common-customizations/email-verification/embed-in-page#step-a-on-the-backend to generate a link for *.vercel.app in case the request is from the staging env. 3) cookie setting: I assume that in prod, the API layer is *.serifhealth.com, but the website is on *.vercel.app. This in turn means that the cookie setting will have to have: - sameSite: none - secure: true Both of these can be set as shown here: https://supertokens.com/docs/thirdpartyemailpassword/common-customizations/sessions/same-site-cookie and https://supertokens.com/docs/thirdpartyemailpassword/common-customizations/sessions/cookies-and-https Also, they will only work on browsers which support third party cookies (or if you enable that on browsers like safari) I'm not sure how changing these will impact the cookie behaviour in prod, but I suspect that it shouldn't. However, if you want the cookie settings to be unchanged in prod, you would need to intercept the response and change the 
Set-Cookie
header values for the cookies on the fly based on which domain queried it. Lmk what works for you and if you would like more info 🙂
@User
m
Got it! Thank you 🙂
We could stand up a third, 'staging' backend and have it be served via the *.vercel.app TLD, it' s a bit overkill for where we are as a company but longer term probably makes sense.
r
Yea. That would work.
4 Views
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