the golang docs suggest handling CORS at the server level: https://supertokens.io/docs/go/usage/handling-cors I have different policies for various paths under the same server, and to date have been returning the Access-Control-* headers from within the handlers for each of those paths I'm just getting to where I'm incorporating the supertokens middleware on the backend ... and because it's inserted between the server and the path-handler, if the middleware hits an error the path-handler never has a chance to send the Access-Control-* headers so: when the middleware hits an error, the error is masked in the browser by a complaint about there being no CORS header in the response

I could do something awkward like .... add my own middleware to handle Access-Control, then supertokens' middleware, then my actual handler

but is there some more obvious pattern?

> I could do something awkward like .... add my own middleware to handle Access-Control, then supertokens' middleware, then my actual handler This is the way I have seen in most projects, so this is what i'd recommend.

How can we have multiple domains (not sub-domains) as the websiteDomain and apiDomain in the appInfo? For CORS, I can pass an array containing the different domains as strings or regex. But passing an array doesn't work for the appInfo.

Do you want to share a session across multiple domains that are not subdomains? Or something else?

If not, you could use something like

window.location.hostname

to set the value of

websiteDomain

Well, I have setup deploy previews for my pull requests which have a different domain and that too different for each PR. With this I also to allow production domain.

Oh, okay. I think I can check if the

window.location.hostname

passes the regex check, if yes then I would set

websiteDomain

as the

window.location.hostname

Yes, and if you are using nextjs, your apiDomain can also be that

Yep, understood. Thank you.

Hey I just started using SuperTokens but sadly i ran into an issue while using it with NextJS. I am currently at step 3 of the NextJS and already have serverless functions in this project (made with go). The app is started using

yarn vercel dev

and runs on localhost:3000

hey @User , unfortunately, we don't support go for login at the moment

If you write your serverless functions using JS, then it would work fine

The login and all other supertokens related serverless functions are written in JS

ahh i see.

Can you should me your auth serverless function?

Also, there is no api like /api/auth. You may want to query /api/auth/signin or something else that exists.. You can see the list of APIs here: https://github.com/supertokens/frontend-driver-interface/blob/master/v1.8.0.md

I am using the one provided here:

what does your backend and frontend config look like?

i mean the appInfo object

its the one provided in this step of the guide.

Have you set

apiBasePath: "/api/auth/"

in the appInfo?

js
let appInfo = {
  // learn more about this on https://supertokens.io/docs/thirdparty/appinfo
  appName: 'SuperTokens Demo App', // TODO: Your app name
  websiteDomain: "http://localhost:3000", // TODO: Add your website domain
  apiDomain: "http://localhost:3000", // TODO: should be equal to `websiteDomain` in case using the `api` folder for APIs
  apiBasePath: "/api/auth/", // /api/auth/* will be where APIs like sign out, sign in will be exposed 
}

This is my current appInfo (i havent changed anything from the guide)

this is really strange...

can you print a console log in the auth serverless function to see if that get's called?

I have a feeling that this is a Vercel problem. I have already asked their support team about it since I also ran into an issue like this while using Auth0

I see..