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

Developers don't understand CORS (2019)

fosterelli.co

Post reply on HN
Print view View original

251–260 of 285 posts

Re: Developers don't understand CORS (2019)

#251

Post by embedding-shape »

JimDabell wrote: post #241
embedding-shape wrote: post #181

Earlier quoted context omitted.

Back in the day when I started web development, websites making their own requests after they loaded wasn't a thing. Eventually, XMLHttpRequest appeared, which let JS do HTTP requests at (page) runtime, and the whole "AJAX movement" kicked off. Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this…

> Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this opens up a whole host of issues, so browsers started limiting websites to just being allowed to make requests to the same Origin. I think that’s overstating it a bit. JavaScript was introduced in Netscape 2.0 and the SOP was introduced pretty…

Yeah, definitely I was simplifying a lot, borderline misleading perhaps even.

Before XMLHTTPRequest there was also a time we were doing requests via ActiveX as well, but I did it so briefly I barely remember how it worked by now, and I'm 99% sure this was exclusively in IE as well, maybe IE4 or IE5. I'm not sure if the issue mentioned earlier with cross-origin requests may have been exclusive to IE as well, but I think there was a larger window than "blink of an eye" that it was a issue.

But again, this is all long time ago, and it was in the beginning of my career, I might misremember and you may very well be right.

Re: Developers don't understand CORS (2019)

#252

Post by jaapz »

stymaar wrote: post #231
gbuk2013 wrote: post #220

Earlier quoted context omitted.

Response is implementation detail: a 404 on second request is one way to do it, a 202 would be another, or 200 with some sort of response to distinguish (e.g. { changed: boolean }). Idempotency just means no state mutation on subsequent request.

> 202 would be another Then you'd return 202 on a request to delete any invalid element, which really doesn't sound right. > 200 with some sort of response to distinguish (e.g. { changed: boolean }). Sounds even worse, and much like APIs that returns 200 with a payload saying {error:"not found"}

Request failed successfully

Re: Developers don't understand CORS (2019)

#253

Post by JimDabell »

embedding-shape wrote: post #251
JimDabell wrote: post #241

Earlier quoted context omitted.

> Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this opens up a whole host of issues, so browsers started limiting websites to just being allowed to make requests to the same Origin. I think that’s overstating it a bit. JavaScript was introduced in Netscape 2.0 and the SOP was introduced pretty…

Yeah, definitely I was simplifying a lot, borderline misleading perhaps even. Before XMLHTTPRequest there was also a time we were doing requests via ActiveX as well, but I did it so briefly I barely remember how it worked by now, and I'm 99% sure this was exclusively in IE as well, maybe IE4 or IE5. I'm not sure if the issue mentioned earlier with cross-origin requests may have been exclusive to IE as well, but I thi…

XMLHTTPRequest was originally an ActiveX object (something like ActiveXObject("Microsoft.XMLHTTP")), that’s probably what you are thinking of. You couldn’t make cross-domain requests with it though. Other browsers then implemented XMLHTTPRequest based on the ActiveX object, and then Internet Explorer supported XMLHTTPRequest and dropped ActiveX.

Before that, people who wanted to make cross origin requests sometimes used Flash but I think that always needed a crossdomain.xml file to work. JSONP was also used, which is where you source a from the remote that calls a function in your own context to pass information in. You needed to be a little more careful with that, but only because you were deliberately passing information in; the browser couldn’t read it by itself.

I’m pretty sure the SOP has been effective in all non-Netscape browsers from as soon as they started supporting JavaScript.

Re: Developers don't understand CORS (2019)

#254

Post by gbuk2013 »

stymaar wrote: post #231
gbuk2013 wrote: post #220

Earlier quoted context omitted.

Response is implementation detail: a 404 on second request is one way to do it, a 202 would be another, or 200 with some sort of response to distinguish (e.g. { changed: boolean }). Idempotency just means no state mutation on subsequent request.

> 202 would be another Then you'd return 202 on a request to delete any invalid element, which really doesn't sound right. > 200 with some sort of response to distinguish (e.g. { changed: boolean }). Sounds even worse, and much like APIs that returns 200 with a payload saying {error:"not found"}

> Then you'd return 202 on a request to delete any invalid element, which really doesn't sound right

It depends on your use-case if you care about this or not. If you do care you will have to handle it either way somehow.

But if you want an idempotent API then a success is more appropriate IMO than an error.

Re: Developers don't understand CORS (2019)

#255

Post by almog »

I think part of what makes CORS hard to remember is the amount of conditional branches it contains, which partially stems from being modeled to have backward compatibility with HTML forms (which defines how CORS behaves for "simple requests). Remove this legacy trap and there are far fewer cases to remember.

Of course, that can't be undone now but I think the original-ish sin was when forms suddenly could perform _both_ cross origin requests _and_ get the ambient authority treatment (i.e. send the user cookies with the request though to be fair, basic auth + forms also enabled similar attacks even before cookies were introduced in the mid 90's).

Re: Developers don't understand CORS (2019)

#256

Post by locknitpicker »

stymaar wrote: post #218
JimDabell wrote: post #177

Earlier quoted context omitted.

> GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests. This is not correct. Safety and idempotency are two different concepts. Safety is when a request does not result in a state change. Idempotency is when the outcome is the same whether you make the requ…

I wasn't aware of the distinction between “safe” and “idempotent”, TIL, thank you. > DELETE is not defined to be safe but it is defined to be idempotent This one puzzles me though. How can DELETE be idempotent? If the first request works then the second one should return a 404, as the key to delete doesn't exist anymore.

> This one puzzles me though. How can DELETE be idempotent?

It's the textbook definition of idempotence. So much so that wikipedia's article on idempotence mentions it and provides links to primary sources.

Re: Developers don't understand CORS (2019)

#257

Post by locknitpicker »

jaapz wrote: post #252
stymaar wrote: post #231

Earlier quoted context omitted.

> 202 would be another Then you'd return 202 on a request to delete any invalid element, which really doesn't sound right. > 200 with some sort of response to distinguish (e.g. { changed: boolean }). Sounds even worse, and much like APIs that returns 200 with a payload saying {error:"not found"}

Request failed successfully

It's the graphql way.

Re: Developers don't understand CORS (2019)

#258

Post by locknitpicker »

spl757 wrote: post #200
Lerc wrote: post #54

Earlier quoted context omitted.

I don't think you can even say CORS does that. The degree to which CORS is poorly understood (I have read numerous (often contradictory) documentation and I don't really understand it.) means that you can't rely on it being implemented properly by an unknown party, If a protocol reaches this level of widespread confusion, I think all bets are off. Even if one end of a system performs correctly, who's to say that the…

A poorly documented, poorly implememented, and poorly understood protocol is a worthless protocol. More than that, it's a potential attack surface, and the idea is to reduce those. If you are the admin of something, and you are putting things into production in which you don't fully understand the implications, because you copy/pasted some crap from stackexchange assuming the person that posted it knew what they are…

> A poorly documented, poorly implememented, and poorly understood protocol is a worthless protocol.

The world seems to manage just well to get CORS to work, though. If developers fucking up implementations of any standard is enough justification to argue that something is worthless, you'd be hard pressed to find any software engineering topic that by your personal definition would be deemed worthless.

Re: Developers don't understand CORS (2019)

#260

Post by 827a »

stymaar wrote: post #142
muvlon wrote: post #39

Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly: > The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us . This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver. No, that does not do that. JavaScript from any other website can still talk to lo…

I don't understand why this is the most upvoted comment. OP is right, and you are wrong. > The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects. GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests.…

> if your server is implemented in a sensible way,

lol

Post reply on HN