Handle http answers after https requests

[maxfscher]

Dear all,

we are recently experiencing an issue regarding the url that is used by the SLIM viewer to retrieve images from a DCM4CHEE PACS server. The problem is expressed as follows: The Slim Viewer is able to communicate with the DCM4CHEE pacs and extracts metadata of image series correctly. However, it fails to extract the requested pixel data and we get a view of the viewer that is similar to issue #142 .
We get an error message that indicates a mixed content problem, as shown in the attached image.

In the Network tab from the browser we can see, that the initial request from the viewer to the DCM4CHEE PACS was done via https,

which we also configure in the local.js file

var hostname=window.location.href.split("//")[1].split("/")[0]
console.log("Hostname: "+hostname)
window.config = {
  path: "/slim",
  /** This is an array, but we'll only use the first entry for now */
  servers: [
    {
      id: "local",
      url: "https://"+hostname+"/dcm4chee-arc/aets/KAAPANA/rs",
      write: true
    }
  ],

The PACS answers then via http and the connection is aborted due to an unsecure connection, which is also reasonable since mixed origin requests indicate unsecure connections.

We are having a pre-build container with SLIM version 0.4.1 lying around, which we integrated to the PACS server via the same local.js as config file and here everything works super fine with the connection to the PACS server.
From the logs we have seen that the error is thrown by DicomWebClient, which is installed as default by SLIM with version 0.8.4. A manual downgrade of the DicomWebClient, to 0.8.2, which was used for SLIM 0.4.1 (the version that works for us), did not help. Are there any other approaches to handle such unsecure connections and automatically transfer them into a secure connection by converting the http request into a https request?

[fedorov]

@cgorman do you have any thoughts about this issue?

[cgorman]

@fedorov @maxfscher Yes, in my experience this is due to the VNA/PACS populating the bulkdataURI fields with its internal URL. We have run into this same problem at MGH and we don't really have a good way of fixing it unfortunately. If you set up a proxy it will still keep the incorrect URL in the field, but there may be some nginx magic to regex bulkdataURIs and replace them with the proxied URL.

[fedorov]

@maxfscher can you please try launching your browser in "insecure mode", which should take care of the CORS problem, and see if in that mode the image is loaded correctly?

[cgorman]

FYI the flag is --disable-web-security in chrome

[maxfscher]

Hi thanks for your help. Yes indeed, with a proxy between the PACS and the viewer, the BulkdataURIs are served via http, even though they are requested via https. For us the CORS extensions did not solve any issues. However, adding the html element in the browser

http-equiv="Content-Security-Policy"
  content="upgrade-insecure-requests"

solves this problem. Adding this manually before each requests helps, or a static solution was for us to add this via a middleware constantly when using a proxy.
I am just curious if there exists also a way in the Viewer to catch these kind of cross-origin-conflicts.

[fedorov]

solves this problem

Meaning you are able to see the image?

[cgorman]

Ok yeah we should be able to just add that content security policy header to requests made by the dicom microscopy viewer* if the URL provided by the configuration is https. I think it's fine since it only touches the protocol, and if an end user has further issues I think it would be the responsibility of the proxy server to handle more complex rewriting.

*I think this is where the change would need to be but I'll double check. Either way I'll link the PR to this issue.

[igoroctaviano]

Addressed by: #160