Turn on CORS #155
Turn on CORS #155
Conversation
Most browsers won't allow connections over the "Internet" when CORS is not configured. This is a problem in Glitch, AWS, GCP, CodeSandbox and other setups where HTTPS encryption is handled by a transparent reverse proxy. Usually nginx, tiny, Apache Mod-proxy, Route 53 or Google Load Balancer.
|
@rayfoss this is a good idea if it's required, but I have a couple thoughts here. First, I feel this should be opt-in, which means options for the server and the CLI implementation. Also, I am about to flip this over to standard JS to get rid of the CoffeeScript requirement. I just haven't done the release. How urgent is this for you? |
|
It's not urgent for me at all. I recall only the GET request is needs it... good point. This is almost exclusively used for local development, DDOS isn't a huge concern, but I lean towards production ready defaults... so I'm leaning towards a super simple option. Test tools: |
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers Noticed this is what's actually used by express@latest response headers with CORS.
|
If this is merged, thgh/rollup-plugin-livereload#66 will make use of it. |
Looks like it's still not released for some reason. Also I don't see how this patch allows to extend this to support COEP. |
Most browsers won't allow connections over the "Internet" when CORS is not configured. This is a problem in Glitch, AWS, GCP, CodeSandbox and other setups where HTTPS encryption is handled by a transparent reverse proxy. Usually nginx, tiny, Apache Mod-proxy, Route 53 or Google Load Balancer.