hum.. it was in a older commit and shouldn't be the one running right now but I'm going to try and redeploy the dev to be sure

This one seems to be a production instance - which is operational.

What's the status of the dev instance on your dashboard?

ah ! sorry, indeed as the dev one was down I used a production to be able to continue working. So the first one I gave is the production and the second is the dev. And the dev is now "restarting" in my dashboard

so yes, the dev one is the one returning the error : supertokens.io:3573/

thanks. We will bring it up ASAP. Sorry for the inconvenience.

Since how long has it been down?

no problem, sorry for the confusion in my question.

I haven't been working on the code for a month so I'm not sure. but this morning it was "restarting" then "active" around noon

Alright. Thanks

@User we have resolved the issue for your dev instance. It was due to an underlying issue with AWS instance in which your core was running..

thank you !

I just tested and indeed everything is now running perfectly 🙂 thanks for your intervention

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?