geosolutions-it/ckanext-provbz

Resources preview

Closed this issue · 4 comments

Resolution of issues related to the resources preview with the URL in DE mode ("daten.buergernetz.bz.it").
Currently the Ckan resources are exposed exclusively with URL "dati.retecivica.bz.it" but can not be displayed in Preview where Ckan is accessed with URL "daten.buergernetz.bz.it".

After some investigations did in the past, it's a Cross Domain problem. CKAN is making a request without going through Ckan's resource proxy because of the resources has the same domain that the CKAN site_url

At the moment the problem seems to affects only PDF resources, a reference to replicate this issue linked below:

http://daten.buergernetz.bz.it/de/dataset/catalogo-beni-culturali

@cezio can you also try to look at this to check if we can understand why this issue happens?

cezio commented

This is because browser refuses to load content from external source due to bad Access-Control-Allow-Origin header. Error from browser:

Failed to load http://dati.retecivica.bz.it/it/dataset/7bd739a1-a270-4c6c-85ac-04548fb2f2cc/resource/37aa7633-7ea0-48bd-b067-50c7f7a9d3c7/download/pbz-parametrerwebservicekulturkueter.pdf: The 'Access-Control-Allow-Origin' header contains multiple values '*, http://daten.buergernetz.bz.it', but only one is allowed. Origin 'http://daten.buergernetz.bz.it' is therefore not allowed access.

This can be fixe by setting * value as allowed origin, or, if we want to have more strict control over CORS, add some middleware that will set allowed origin header depending on host requested (so dati. server will send daten. in header, and vice versa).

@cezio, it's not possible to set * for CORS in production server. Can you please describe in detail the alternative you mentioned?

cezio commented

it's not possible to set * for CORS in production server. Can you please describe in detail the alternative you mentioned?

Few details to explain situation:
Response headers for http://dati.retecivica.bz.it/it/dataset/7bd739a1-a270-4c6c-85ac-04548fb2f2cc/resource/37aa7633-7ea0-48bd-b067-50c7f7a9d3c7/download/pbz-parametrerwebservicekulturkueter.pdf

contain duplicated Access-Control-Allow-Origin headers:

Accept-Ranges:bytes
Access-Control-Allow-Headers:x-requested-with, Content-Type, origin, authorization, accept, client-security-token
Access-Control-Allow-Headers:X-CKAN-API-KEY, Authorization, Content-Type
Access-Control-Allow-Methods:POST, PUT, GET, DELETE, OPTIONS
Access-Control-Allow-Origin:http://daten.buergernetz.bz.it
Access-Control-Allow-Origin:*
Access-Control-Max-Age:1000
Cache-Control:no-cache
Connection:Keep-Alive
Content-Range:bytes 0-392016/392017
Content-Type:application/pdf
Date:Thu, 08 Feb 2018 13:18:18 GMT
ETag:"1504874299.17-392017"
Keep-Alive:timeout=900, max=200
Last-Modified:Fri, 08 Sep 2017 12:38:19 GMT
Pragma:no-cache
Server:PasteWSGIServer/0.5 Python/2.7.5
Transfer-Encoding:chunked

My guess is that header with * value is added by http server (nginx, apache) to response. Adding middleware in ckan, won't solve this because faulty header (with *) will be added anyway (if my assumption is correct).

Alternative take is to add plugin with IMiddleware implementation (http://docs.ckan.org/en/latest/extensions/plugin-interfaces.html#ckan.plugins.interfaces.IMiddleware), which would add Access-Control-Allow-Origin header to response. But this would be duplication of existing functionality in CKAN: