Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers don't understand CORS

fosterelli.co

Post reply on HN
Print view View original

41–50 of 366 posts

Re: Developers don't understand CORS

#41

Post by chrisfosterelli »

zenexer wrote: post #31

The author suggests that using CORS to allow https://zoom.us with http://localhost:19421 is possible. This is factually incorrect. Mixed content policies prevent the http: origin from communicating with the https: origin. "For very intentional reasons, the browser explicitly ignores any CORS policy for servers running on localhost." That last sentence is incorrect – Chrome does respect CORS headers for localhost webs…

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is possible and not factually incorrect.

If for some reason that doesn't work for your app, the post also mention two secure alternatives: the native client can install a self-signed cert, or you can use a browser extension with the native messaging API.

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=903966

[1]: https://chromium.googlesource.com/chromium/src.git/+/130ee68...

[2]: https://github.com/w3c/webappsec-mixed-content/commit/349501...

Re: Developers don't understand CORS

#42

Post by nathan_long »

EGreg wrote: post #24

Seriously wondering! Why is Zoom worth $2B and companies are paying per minute plans to host meetings when you can now host your own videoconferencing software easily on your own website or app or intranet using WebRTC, branded, with your own experience, widgets, and it can all be open source? All you need to pay for are dumb TURN servers eg from twilio. Plus it would be far more secure. For example we built https://…

How many people can you have in a single meeting?

Re: Developers don't understand CORS

#43

Post by yeldarb »

zenexer wrote: post #31

The author suggests that using CORS to allow https://zoom.us with http://localhost:19421 is possible. This is factually incorrect. Mixed content policies prevent the http: origin from communicating with the https: origin. "For very intentional reasons, the browser explicitly ignores any CORS policy for servers running on localhost." That last sentence is incorrect – Chrome does respect CORS headers for localhost webs…

Could they sign and distribute a cert for localhost.zoom.us and point the DNS at 127.0.0.1?

Re: Developers don't understand CORS

#44

Post by chrisfosterelli »

edejong wrote: post #19

The reason the developers didn't use CORS is because active mixed content isn't allowed. You simply cannot call ' http://localhost' from a https domain. For a medical SaaS application which needed to communicate via USB I created a self-signed certificate during installation and added it to the trust store to be able to call active content on localhost. Previously, we used NPAPI (which, when used correctly was more s…

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is allowed.

If for some reason that doesn't work for your app, the post also mention two secure alternatives: the native client can install a self-signed cert, or you can use a browser extension with the native messaging API. You touched on this too!

My point here is not the specific example solution -- there's lots of alternatives and yes it depends on the situation and browser support requirements. But NONE of them are a reason to allow requests from every origin.

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=903966

[1]: https://chromium.googlesource.com/chromium/src.git/+/130ee68...

[2]: https://github.com/w3c/webappsec-mixed-content/commit/349501...

Re: Developers don't understand CORS

#45

Post by jandrese »

phkahler wrote: post #6

Not a web dev. Can anyone tell me what CORS is ultimately used for? Not the literal technical details, the higher level what does it enable sites to do? And is that for them or their visiters?

It prevents someone with the following pseudo-javascript on their random website (or injected from the ad network) from working:

  onPageLoad()
  { 
    for ( x = 1; x

Re: Developers don't understand CORS

#47

Post by anaphor »

pixelperfect wrote: post #23
mehrdadn wrote: post #11

Earlier quoted context omitted.

Also not a web dev, but if I'm remembering it correctly (someone please correct me if I'm wrong), the way I understood it was: Whenever your browser sends any request to any site, it sends the cookies(/other auth data) associated with that site along with it. In other words, cookies are fundamentally just associated with the receiver, not the sender. So the "solution" is for the receiver to block requests from the wr…

I'm pretty sure you're incorrect - requests to sites different from the one you are currently on will not include auth data by default because of the same-origin policy. The auth data would only be included if the server that the request is being sent to responds with an Access-Control-Allow-Origin header whose value matches the origin the request was made from.

> I'm pretty sure you're incorrect - requests to sites different from the one you are currently on will not include auth data by default because of the same-origin policy

Not necessarily true. You can have Javascript running on evil.com that submits a form to banking.com and it will send your session cookies for banking.com along with the request. It's just that evil.com can't read the response content.

Re: Developers don't understand CORS

#48

Post by vbezhenar »

edejong wrote: post #19

The reason the developers didn't use CORS is because active mixed content isn't allowed. You simply cannot call ' http://localhost' from a https domain. For a medical SaaS application which needed to communicate via USB I created a self-signed certificate during installation and added it to the trust store to be able to call active content on localhost. Previously, we used NPAPI (which, when used correctly was more s…

I think that Chrome allows calling http://localhost from https domain. Other browsers should fix that instead of every application installing their custom certificates into trust store.

Re: Developers don't understand CORS

#50

Post by jdfellow »

yeldarb wrote: post #43
zenexer wrote: post #31

The author suggests that using CORS to allow https://zoom.us with http://localhost:19421 is possible. This is factually incorrect. Mixed content policies prevent the http: origin from communicating with the https: origin. "For very intentional reasons, the browser explicitly ignores any CORS policy for servers running on localhost." That last sentence is incorrect – Chrome does respect CORS headers for localhost webs…

Could they sign and distribute a cert for localhost.zoom.us and point the DNS at 127.0.0.1?

No, because you'd have to distribute the private key for the local webserver to be able to sign the connection challenge.
Post reply on HN