-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DISCUSSION: proxy: add CORS headers to /twitcher/, affect all services behind it #450
base: master
Are you sure you want to change the base?
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. |
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, nofollow
header (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-Tag
header 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