Live data from Hacker News

Developers don't understand CORS (2019)

fosterelli.co

281–285 of 285 posts

Re: Developers don't understand CORS (2019)

#281

Earlier quoted context omitted.

That’s… not what cors does? CORS will only block browser-mediated “non-simple” requests, they don’t prevent other systems from accessing it as long as they don’t use a browser (or disable CORS in a headless browser).

I'm pretty sure they understand that since they wrote that the resources will need to be proxied. They just want to prevent hotlinking/leeching.

Hotlinking/leeching applies to img or media assets, CORS offers NO protection from that AT ALL.

Re: Developers don't understand CORS (2019)

#282
post #252

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

Not really, more like succeed without having to do anything.

The key is the perspective of what success is: it’s the state where the resource does not exist, or is the action having deleted the resource. But 200/202 is perfectly capable of expressing the distinction in the latter case as well.

Re: Developers don't understand CORS (2019)

#283
post #279

Earlier quoted context omitted.

I think perhaps it’s generational. If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along and CORS was created to bypass this security. Therefore to do the thing you want to do, you need to enable CORS. No problem, that’s pretty easy. If you only picked up web development after CORS existed, then you try to make a cross-origin request; the browser unde…

> If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along They weren't though. We had to adjust in the 2010s so existing code wouldn't break. It was something like, Chrome set a deadline after which it would be forcing the same-origin security by default, where it was off or optional before.

That’s not correct at all. Are you confusing it with SameSite or something like that?

Re: Developers don't understand CORS (2019)

#284
post #279

Earlier quoted context omitted.

> If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along They weren't though. We had to adjust in the 2010s so existing code wouldn't break. It was something like, Chrome set a deadline after which it would be forcing the same-origin security by default, where it was off or optional before.

That’s not correct at all. Are you confusing it with SameSite or something like that?

I may be wrong about the specific security thing involved, but I know it would have broken ajax requests (probably XMLHTTPRequest, not fetch) to different domains had we not made changes to deal with it. They worked without issues before that.

Re: Developers don't understand CORS (2019)

#285
post #284

Earlier quoted context omitted.

That’s not correct at all. Are you confusing it with SameSite or something like that?

I may be wrong about the specific security thing involved, but I know it would have broken ajax requests (probably XMLHTTPRequest, not fetch) to different domains had we not made changes to deal with it. They worked without issues before that.

You could not make cross-domain Ajax requests at all until CORS came along. There were lots of workarounds people had to invent (e.g. JSONP, Flash shims, proxying, etc.) precisely because this security barrier has been in place since the mid-90s, a couple of decades before CORS came along.

The whole point of CORS was to enable cross-domain requests.

Post reply on HN