What is the origin for CORS?

Do I’ve to provide “https://clientid.ext-twitch.tv” in the EBS allow origins

For an EBS, that your Twitch Extension makes fetch calls to.

Yes, you will need a cors origin header on the server.

In express for example

This allows “everyone”

app.use(cors());

Or you can be specific such as

app.use(cors({
    origin: [
        'https://CLIENTID.ext-twitch.tv',
    ]
}));

Correct but we’ve build and published various extensions and mostly on developing a new ext sometime on hosted test we face cors issue and sometime not, cors issue stays for few hours or sometime days then disappear and then appear again like weird situation, does it have something to do with Twitch side bug etc, or did anyone reported this type of issue before?

CORS issues are all on you.

I’ve never had a problem like what you describe.

And I also build and publish various extensions.

Hosted test and release are the same when it comes to the domain used for the calls.

My code examples above are from my live extension EBS’s.

CORS issues are all controlled by the EBS and nothing to do with Twitch.
If you rever to local test then the origin will be different.

Ok, yeah all of our extensions are working fine in release without cors issue, it’s just happen in hosted test, so maybe release and hosted test aren’t on equal environment/system. We don’t do much testing in local test due to it’s different origin.

They are though.

The URL that the extension is on is the same for hosted test and release.
The whole point of hosted test is that it’s identical to release.

Going from hosted test to release just makes the extension public/visible to viewers.
It doesn’t move where the files are/change the domain.

So if having CORS issues, either use a catch all CORS rule, or debug the issue.

Some errors can manifest as a CORS issue, for example you protest your API route only with a CORS header, but for some reason yoru API route 404’s your server then issues a redirect to a 404 page which doesn’t ahve a CORS header.

This then raises a CORS error, but it’s not a CORS error, it’s a 404.

Another example is that the NGINX in front of your NODE server is up, but the Node server is down. This raises a 503 error, as the backend is down, BUT will raise a CORS error as theres no CORS headers on the 503 page that nginx generates.

So it’s possible that you don’t have a CORS error but something else, that end logs in the browser as a CORS error.

So if you get CORS error you need to leaf thru your network tools carefully.
And consider additional logging on your server to monitor what actually is going on/attempting to be loaded.

Thats why when I do use “lists of domains” in my CORS config, I list my localtest in that URL, since my localtest isn’t “localhost” its’ a real domain with a reverse SSH Tunnel.

So my “live” nginx production server handles the SSL and real domaining for extension testing.

Localtest just means “not on Twitch’s CDN” so you could have your localtest be the same server as your EBS for example. Then you have SSL handled and a known URL to add to yoru CORS list when using “lists” of domains rather than a catch all.

Maybe some issue with our EBS, it happens mostly in hosted test and not in release this lead me to ask the question and your localtest setup is interesting.

Thanks BarryCarlyon!

Sounds very odd since they are the same

Yeah it’s “modelled” to be as close to hosted/release as possible.

So I only do “spot checks” on hosted test before review. Saves juggiling zip files