Closed tdipisa closed 6 years ago
@cezio can you also try to look at this to check if we can understand why this issue happens?
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?
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:
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