thegooddata / webapp

TheGoodData web application
http://www.thegooddata.org
GNU General Public License v3.0
3 stars 2 forks source link

Setup Access-Control-Allow-Origin in nginx for our subdomains #140

Closed atrandafir closed 9 years ago

atrandafir commented 9 years ago

There are two issues related to loading the same font files from webapp, blog, and collaborate:

https://github.com/thegooddata/webapp/issues/129 https://github.com/thegooddata/social/issues/40

@JuanMenendezBuitrago and @josereyero tried to include the fonts fron www.thegooddata.org and they both ran into the same problem:

Font from origin 'https://www.thegooddata.org' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://blog.thegooddata.org' is therefore not allowed access.

This is a new thing we're all learning I think. I had no idea that fonts also need this. I did knew that cross domain AJAX requests needed this, but not fonts.

Anyways, in order to make it work, we should setup nginx to add the Access-Control-Allow-Origin header.

There is a easy solution, that would add Access-Control-Allow-Origin: * and allow all domains to make remote requests to our server.

But since we should keep security in mind, we should setup nginx with a proper validation of the domain and have some kind of whitelist of domains allowed. Right now we only need blog and collaborate subdomains but we could add it for any subdomain of our main domain.

So what we must do is to configure Nginx to add Access-Control-Allow-Origin header only when requests come from our subdomains.

I've found some links that maybe can give you some more information: https://gist.github.com/alexjs/4165271 https://gist.github.com/algal/5480916 http://stackoverflow.com/questions/14499320/how-to-properly-setup-nginx-access-control-allow-origin-into-response-header-bas

Feel free to do this with any technique that you know as I am not very familiar with it. When it is done we should ask @JuanMenendezBuitrago to test it and see if it works.

PS: Other solution could be to create a subdomain called static.thegooddata.org and simply add it for Access-Control-Allow-Origin: * (any domain) but that involves separating our assets and put them on a subdomain. This way any domain can load the assets since we do not need to have a whitelist, because on the static subdomain no ajax requests can be made since it has no php.

agonbar commented 9 years ago

I'm familiar with Access-Control-Allow-Origin when working with json APIs. Isn't there any alternative? Like having the fonts in both places, activating Access-Control-Allow-Origin should be our very last option, as is not recomended by the w3c because there are various ways around it and can be a potential breach in security.

atrandafir commented 9 years ago

Well if it is a headache or possible security problem we can just forget about this for now since it has minor importance and so cancel the two related issues and leave the fonts repeated in each application.

So yes we can have them in both places there's no problem, just wanted to save some bandwidth for mobile devices but as I say I think it has too little importance and we should not waste too much time on it right now.

@marcosmenendez if you agree we can cancel the sharing of fonts between applications and leave it as it is now.

marcosmenendez commented 9 years ago

Agree. It is not high priority. I set it as postponed