-
-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Cors headers #119
fix: Cors headers #119
Conversation
src/commands/serve.js
Outdated
return [ | ||
simplehttp2server, | ||
'-cors', '*', | ||
'-cors', `https://localhost:${port}`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we allow an options.cors
that gets appended to this as a CSV?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here you go. FYI simplehttp2server is able to add only one origin.
@developit this is a breaking change - as it can break stuff on things like now.sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
@rkostrzewski maybe we should check if there is an env var we can watch for? |
@developit we can check for |
I'd wait for @developit since IMHO this is a major version bump and maybe something smaller will come along. |
I think I overestimated the breakage this would cause initially - really the only time someone would run into an issue is if they are trying to fetch assets from their preact-cli output on a page with a differing origin. I think that's a fairly small set of people - I've had such a usecase before, but I would expect to have to muck around with hostnames/headers a bit to make things work. Should we wait for a bit of breakage to accumulate and make a 2.0.0, or merge and cross our fingers? haha |
TBH, I'm not fully aware of the implications, but I have a feeling that (in development) that would be a tiny tiny subset of people. In production, I'd assume that the requesting origins would be known & specified... or just reverted back to |
The last time I ran into this was proxying my initial bundle, but leaving it to reference its associated webpack assets from a CDN. The thing is, I had to manually configure Webpack to set the public path to the CDN. Maybe we could generate a list of allowed origins using some more information:
The combination of these would handle a whole bunch of cases, really leaving only a few where there's not enough information to determine safety. Also good point - if someone found this to be an issue they can still do FWIW I believe this change only applies to the production web server(s) bundled in. |
Simple http2server doesn't support multiple origins 😢 |
(continuing from slack lol) When you suggested setting the header from |
@developit this change allows only
https://localhost:port
origin to access served app.