Open marien-probesys opened 2 years ago
Not sure headers for CORS can be done directly in the backend.
Why couldn't we? They just normal headers, for instance:
header('Access-Control-Allow-Origin: *');
Or with Slim: https://www.slimframework.com/docs/v3/cookbook/enable-cors.html
ah ok, so yes. But for performances, it's better on webserver instead PHP because webserver call php each time when managed in the php. When it's on webserver, not call the php if CORS not pass.
I just tried, but Nginx calls PHP even if the CORS headers don't pass. Even though, this has no impacts if we allow all the origins (the requests would always be accepted, and so, passed to PHP).
Seriously? that's seems not normal ;( But ok
The Nginx add_header
directive only adds the header to the response, I'm not surprised it doesn't verify the origin ;)
I just discovered a related issue: add_header
only adds headers for some HTTP status code. If the request fails with an error 401 (e.g. wrong credentials during authentication), the CORS are not declared and the frontend can't access the error.
It is possible to add always
to the directive to always add the header.
Reference: http://nginx.org/en/docs/http/ngx_http_headers_module.html
At the moment, some HTTP headers (e.g. CORS) must be declared in the webserver configuration (see the documentation).
To facilitate the updates (if we need to change a header for instance), the headers should be directly declared by the backend.
For better security, we might have to let the administrator configure which origins he wants to allow (could be done in the PHP configuration file).