Why run request handlers "successfully" if the request fails CORS?
See original GitHub issueIf a request fails CORS as specified by this module’s configuration, the module will not set the CORS headers on the response. However, it will still call next
, causing the usual request handler to run. This can be a problem if the request is expensive to handle, or has side effects.
What is the thinking behind this? It seems reasonable to terminate the request immediately, or at least call next
with an error, if it’s going to fail client-side due to the lack of CORS headers.
Here is a small project demonstrating this issue: https://github.com/mixmaxhq/cors-response-tester.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:8 (5 by maintainers)
Top Results From Across the Web
Fixing Common Problems with CORS and JavaScript
Tutorial: This post walks through troubleshooting and fixing common problems associated with calling REST APIs from JavaScript.
Read more >Chapter 4. Handling preflight requests - CORS in Action
This chapter will examine what a preflight request is and when it's used. Next it will introduce headers the server can use to...
Read more >I got a CORS error, now what? - DEV Community
If the preflight fails, it is usually due to either a misconfiguration of your infrastructure, and so it is possible that you did...
Read more >CORS errors and how to solve them - Topcoder
Why is CORS blocked? ... It is to prevent cross-site request forgery. Let's say you log in to facebook.com and your browser stores...
Read more >Handling CORS (Cross Origin Resource Sharing) in Web Apps
CORS error · with wildcard *, the server is allowing requests from all origin to be able to fetch · The value of...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
HI @wearhere sure, feel free to make that PR. I’m a little confused, because it won’t even work for your use-case; a missing
Origin
header won’t be a mismatch at all, just FYI. Also, I think the line references you gave are not at all where those check should go, because they would only apply to the dynamic origin function, not all the others like a static origin string, array, etc.Please be aware that this module supports all Node.js and not is Express-only, so you need to use only the Node.js API https://nodejs.org/dist/latest-v6.x/docs/api/http.html#http_class_http_serverresponse
Hi @wearhere you were asking, technically why the default behavior was the way it was, which is that the default is closest to the specification. We provide mechanisms to differ from the spec as I provided above for your use-case, so I hope that helps.
The CORS specification was never designed as a security mechanism to prevent routes from being called; it was only designed as a mechanism to allow a hole to be added to the cross-origin rules of browser user agents. The specification is designed such that a “CORS failure” should look exactly as if the server has no idea what CORS is–in which case the request will still go through.
I would suggest bring this up to the W3C if you would like implementers to implement it differently, and I would be happy to do so; this really isn’t the forum to get changes progressed through the specification 😃