re: CORS, In A Way I Can Understand VIEW POST

re: Ok I have some questions since i have been struggling with this for ages now. If Miss Patty comes over and someone knocks on the door can she let ...

The pre-flight request (OPTIONS) is issued by the browser before the original request is sent to the server and will mostly match the intended request. For illustration, GET /books/1234 would look something like OPTIONS /books/1234. The server should be setting the pre-flight response appropriate to the resource on the server. So OPTIONS /wall?paint can return different allowed methods than OPTIONS /ceiling?paint. It is a responsibility of the server to enforce specific CORS policies.

I am of the personal opinion that CORS is currently pointless since browsers have to opt-in to implementing this control. It does a great job of being descriptive to the browser user-agent of the capabilities of the resource, but that description generally is hard to describe in any efficient way (assuming large sets of APIs).

If you are serving traffic from user-agents that are not a browser, than the API is essentially acting public anyway and the CORS control is no longer triggered. This is where it becomes important to authenticate the User Principal and authorize against identity claims as to what that user can do with that public resource. This is where OAuth and Open ID Connect play.

code of conduct - report abuse