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.
Developers don't understand CORS (2019)
281–285 of 285 posts
Re: Developers don't understand CORS (2019)
#282Earlier 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
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)
#283Earlier 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.
Re: Developers don't understand CORS (2019)
#284Earlier 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?
Re: Developers don't understand CORS (2019)
#285Earlier 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.
The whole point of CORS was to enable cross-domain requests.