My company's system requires a multi-tenancy implementation, and each of our clients will have their own specific front-end address with the supertokens frontend implemented via proxy with their own url (www.client1.com, www.client2.com etc), however our backend code will be in a single server with a single URL and serve all web calls. This is creating a massive problem with the Supertokens CORS config because it apparently does not allow the value for the Access-Control-Allow-Origin response header to be *, and in our case it must be. What can be done?

Hi, The cors middleware should let you pass an array as the domain where you can provide a list of all the frontend domains you want to allow

But then I would have to manually maintain this list. Our goal is to decrease the amount of maintenance when adding a new tenant. Why couldn’t we just use the * wildcard?

When adding the CORS middleware you could set it to

*

as well, were you getting any errors when you tried that?

yupp, I keep getting either one of the last two errors described in this page: https://supertokens.com/docs/passwordless/troubleshooting/cors-issues#error-cannot-use-wildcard-in-access-control-allow-origin-when-credentials-flag-is-true Both of them point that the error comes from using the * wildcard, and suggest changing the value of the header to the specific origin. From this it seems that the wildcard is not supported :/

Hmm, can you open an issue about this? One of the team members will have a look at this sometime next week

yupp, I already scheduled a meeting for it next Tuesday with Rishabh Poddar

Ah alright then

regarding the issue, you mean on the github repo, yeah?

If you have a call scheduled the issue isn’t necessary

if it's possible that this will be taken a look at sooner than the call then I 'd actually prefer to open the issue, we have a tight deadline to implement this auth feature 😅

Unfortunately he’s the one who would reply on the issue anyway and he’s not available till next week so I’m afraid it would be the same timeline, but you could open the issue anyway in case he gets a chance to have a look before then

ahh ok, thanks for flagging

Yep

commenting the github issue for whoever comes across the same problem: https://github.com/supertokens/supertokens-node/issues/462

Hey @monsterdonio

Hi there! The problem actually isn’t in the code implementation; it’s in my api gateway declaration. In the code, I’m using the getOrigin function of the middy http-cors middleware, and I basically return the value of the Allow-Origina header as the origin of the reauest always, so that’s good. However in my gateway, when I set the x-amazon-apigateway-integration responses field with the wildcard, the frontend supertokens code’s seems to be rejecting it upon the request.

Ah I see. So wildcards won’t work cause we are using cookies.