search

geosolutions-it / ckanext-provbz

Provincia di Bolzano Ckan Theme
0 stars 6 forks source link

Resources preview #21

Closed tdipisa closed 6 years ago

tdipisa commented 6 years ago

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

tdipisa commented 6 years ago

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

cezio commented 6 years ago

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).

tdipisa commented 6 years ago

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

cezio commented 6 years ago

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: