It seems that the server option's route defaults are no longer used when route specific config options are present. v10.5.0 worked as expected, and v11.0.0+ does not.
$ curl -X GET http://localhost:8080/session -H 'Origin: mydomain.com' -H 'Access-Control-Request-Method: "GET"' -v
Note: Unnecessary use of -X or --request, GET is already inferred.
* Trying ::1...
* connect to ::1 port 8080 failed: Connection refused
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)> GET /session HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.45.0
> Accept: */*> Origin: mydomain.com
> Access-Control-Request-Method: "GET">< HTTP/1.1 200 OK
< vary: origin
< access-control-allow-origin: mydomain.com
< access-control-expose-headers: WWW-Authenticate,Server-Authorization
< cache-control: no-cache
< content-length: 0
< Date: Thu, 17 Dec 2015 06:02:48 GMT
< Connection: keep-alive
<* Connection #0 to host localhost left intact
Is this intentional? I much prefer being able to have default values in place and explicitly override specific keys, rather than have to respecify all values for a route where only one of them needs customized.
The text was updated successfully, but these errors were encountered:
The flip scenario is much more problematic because allowing credentials on a single route will override the connection origin default and change it to '*' which is a security hole. It is not a critical one but in some configuration would open an API to CSRF attacks.
You should install v11.1.4 or newer if you combine server level, connection level, or route level CORS configuration to ensure the result is as-expected (each level applied to the previous). This bug caused each level to override the previous causing the higher level defaults to be ignored. When the higher level config includes security restrictions (like origin), those restrictions can be overridden by less restrictive defaults (e.g. origin defaults to all origins).
It seems that the server option's route defaults are no longer used when route specific config options are present. v10.5.0 worked as expected, and v11.0.0+ does not.
But adding a 'cors' configuration object to the route, causes the 'access-control-allow-credentials' header to be dropped
Is this intentional? I much prefer being able to have default values in place and explicitly override specific keys, rather than have to respecify all values for a route where only one of them needs customized.
The text was updated successfully, but these errors were encountered: