DISCUSSION: proxy: add CORS headers to /twitcher/, affect all services behind it #450
Conversation
|
Proposal to white list https://raven.uwaterloo.ca/ |
Unfortunately I don't think it will even do that. If we want to apply the cors headers everywhere, why not apply it at the proxy level instead of on twitcher. Not all requests will go through the twitcher proxy necessarily. Some components (geoserver, jupyterhub, all the monitoring components, secure-data-auth) just use twitcher's verify endpoint to check whether a user has access, in those cases, the cors headers wouldn't be included. Jupyterhub and the monitoring components probably won't matter for cross-site scripts but the others will matter I'm sure.
Is this when making a cross-origin request or everywhere? You might have to add the
This would have to be configurable as not every deployment would want the same domains.
This one will require some thought. Do you know if there are recommended best-practices for setting these? |
Sorry I meant adding CORS headers to the proxy location
Everywhere. But I think I understood how this works. So probably each time that
Agreed it has to be configurable. I was reading how to make it configurable, it's not so simple. I didn't know "if is evil" in Nginx config and our current Some interesting read I found: https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html https://www.juannicolas.eu/how-to-set-up-nginx-cors-multiple-origins/
Have not had time but yes we should follow some newer best practices. That |
That is my current understanding of what is already applied by the following, which includes Setting it under
Maybe? For the |
I understand... what I was saying is that there are components that are not behind twitcher that will not be affected by this change. |
|
@tlvu @mishaschwartz 
But CORS blocks the response from our server : 
The solution I found is actually better than the proposed change. This effectively "undo" the server-wide rule: And my responses contain the desired headers: This solution is "safer" since it is only an API endpoint, and there is little (if any) data that could be extracted via XSS because no JS is involved. There could also be a specific variable to enable only the What do you think of this approach? |
|
I agree that it's a nice feature and I like the flexibility. I would prefer to add an option to just allow same-origin and geojson.io for the stac endpoint (instead of turning off cors protections for stac). My suggestion would be to create a variable that allows geojson.io from stac and only enable that variable if the stac-populator component is enabled as well. |
|
I have tried setting location /stac {
proxy_pass_header 'Access-Control-Allow-Origin';
add_header Access-Control-Allow-Origin "${BIRDHOUSE_FQDN},geojson.io";
[...]
}That does not work. They are inserted as-is, instead of multiple entries. The servers accessing it cannot parse the header appropriately. Instead, one of the solutions listed in https://serverfault.com/questions/958965/nginx-enabling-cors-for-multiple-subdomains using IMO, it should not be specific to geojson.io. The API could be used by others that I wouldn't mind them accessing, so it needs to be a configurable list. |
|
@fmigneault what about something like #599 ? |
Looks promising. I'll comment directly on it. |
## Overview - Allow each service to specify values for `Access-Control-Allow-Origin` Previously, if a `location` block in the `nginx` configuration for a given service included the cors helper configuration (with `include /etc/nginx/conf.d/cors.include;`) then all origins were allowed by default. This was done by setting the header `Access-Control-Allow-Origin: *` which works well but is a bit too permissive since it allowed __all__ origins. This change introduces a mechanism to specify specific additional allowed origins by setting the `$access_control_allow_origin` nginx variable in the `location` block before including the `cors.include` file. For example: ``` set $access_control_allow_origin http://example.com; include /etc/nginx/conf.d/cors.include; ``` will set the value of the `Access-Control-Allow-Origin` response header to `http://example.com`. By default, the header value will be `*` if `$access_control_allow_origin` is not set (to maintain backwards compatibility). To specify multiple allowed origins, use a `map` directive (see the implementation for `components/stac` for an example). - Set allowed CORS origins for `stac` through an environment variable This change implements this flexibility for the `components/stac` component. By setting the `STAC_CORS_ORIGINS` variable a user can specify allowed origins for responses from the `components/stac` component. For example, setting the following: ``` export STAC_CORS_ORIGINS='https://example.com ~^https?://(www\.)?other\.example\.com$' ``` then requests from https://example.com and http://other.example.com will get a response with the `Access-Control-Allow-Origin header` set to their origin, but http://example.ca will not. Note that this breaks backwards compatibility slightly since previously all origins were allowed for `/stac` by default. To keep the backwards compatible behaviour you can set: ``` export STAC_CORS_ORIGINS='~.*' ``` to match all origins. ## Changes **Non-breaking changes** - Adds mechanism to allow services to have more control over CORS headers **Breaking changes** - responses from `/stac` no longer set `Access-Control-Allow-Origin: *` by default ## Related Issue / Discussion - As discussed in #450 ## Additional Information ## CI Operations <!-- The test suite can be run using a different DACCS config with ``birdhouse_daccs_configs_branch: branch_name`` in the PR description. To globally skip the test suite regardless of the commit message use ``birdhouse_skip_ci`` set to ``true`` in the PR description. Using ``[<cmd>]`` (with the brackets) where ``<cmd> = skip ci`` in the commit message will override ``birdhouse_skip_ci`` from the PR description. Such commit command can be used to override the PR description behavior for a specific commit update. However, a commit message cannot 'force run' a PR which the description turns off the CI. To run the CI, the PR should instead be updated with a ``true`` value, and a running message can be posted in following PR comments to trigger tests once again. --> birdhouse_daccs_configs_branch: master birdhouse_skip_ci: false
Overview
This PR is rather to start a discuss than ready to merge. That's why there is no CHANGES.md update.
So I needed to add CORS allow headers for Thredds, so our partner javascript webapps running on other domains than pavics.ouranos.ca can hit our Thredds, so we act as the backend for their frontend.
Is adding the CORS header to Twitcher okay with you guys? Because the new headers will affect all other services behind Twitcher.
By adding this CORS header, I lost the
X-Robots-Tag: noindex, nofollowheader (optional-components/x-robots-tag-header) ! Is that expected? Or the way I add headers to Twitcher is wrong? I was just doing the same thing as all the existing services. TheX-Robots-Tagheader is important to avoid being hit by crawlers.This is what we return https://github.com/bird-house/birdhouse-deploy/blob/97ee8da24821391aeef52b13ea9adda28f919085/birdhouse/components/proxy/conf.d/cors.include
This is already enough
I think perhaps we should not allow-origin * but a list of known partners domain? And trim down the allow-headers list?
I am not security expert so I want to hear from you guys.
birdhouse_daccs_configs_branch: master
birdhouse_skip_ci: false