https://supertokens.com/ logo
Title
m

monsterdonio

12/22/2022, 11:59 PM
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?
n

nkshah2

12/23/2022, 3:47 AM
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
m

monsterdonio

12/23/2022, 8:45 AM
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?
n

nkshah2

12/23/2022, 9:11 AM
When adding the CORS middleware you could set it to
*
as well, were you getting any errors when you tried that?
m

monsterdonio

12/23/2022, 12:48 PM
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 :/
n

nkshah2

12/23/2022, 12:50 PM
Hmm, can you open an issue about this? One of the team members will have a look at this sometime next week
m

monsterdonio

12/23/2022, 12:52 PM
yupp, I already scheduled a meeting for it next Tuesday with Rishabh Poddar
n

nkshah2

12/23/2022, 12:53 PM
Ah alright then
m

monsterdonio

12/23/2022, 12:53 PM
regarding the issue, you mean on the github repo, yeah?
n

nkshah2

12/23/2022, 12:53 PM
If you have a call scheduled the issue isn’t necessary
m

monsterdonio

12/23/2022, 12:54 PM
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 😅
thanks for the pointers!
n

nkshah2

12/23/2022, 12:55 PM
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
m

monsterdonio

12/23/2022, 12:55 PM
ahh ok, thanks for flagging
n

nkshah2

12/23/2022, 12:55 PM
Yep
m

monsterdonio

12/23/2022, 2:51 PM
commenting the github issue for whoever comes across the same problem: https://github.com/supertokens/supertokens-node/issues/462
r

rp

12/24/2022, 7:47 AM
Hey @monsterdonio
You can provide a function to the CORS middleware I think. In that function, you could query a db or somewhere to get a list of tenants domains.
m

monsterdonio

12/24/2022, 10:19 AM
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.
r

rp

12/24/2022, 7:29 PM
Ah I see. So wildcards won’t work cause we are using cookies.