Wado url always uses HTTP, even when server.base.url etc are set to HTTPS about weasis-pacs-connector HOT 5 CLOSED

Hi Nicolas,

To answer my own question in case anyone else finds it useful, I eventually found after lots of trial and error that the exact settings needed were:

In the weasis-pacs-connector.properties file:

weasis.base.url=https://the.front.end.server.name:443/weasis
pacs.wado.url=https://the.front.end.server.name:443/wado

Things that I tried that were incorrect:

• put the weasis.base.url into the weasis-pacs-connector.properties file, and the pacs.wado.url into the dicom-dcm4chee-local.properties file
• try to use ${server.base.url}

I had already seen that you had mentioned this in a previous question:

https://groups.google.com/d/msg/dcm4che/FUsNwpBWW0o/cS41m1KjRS0J

..but I had assumed that the ${server.base.url} bug you mentioned there was already fixed in version 6.1.3, since that thread was quite old. And I didn't fully appreciate the fact that the pacs.wado.url setting had to be in the main file as well (even though you said it!). My bad.

I would like to follow up slightly and point out that what I was looking to do (run tomcat as pure HTTP with a HTTPS-only nginx in front) is still not possible because:

• the default j_security_check behaviour of tomcat is to go to HTTP; it doesn't send the password over HTTP at least, but still I'd prefer if the session setup was not sent via HTTP.

It looks like I'll have to create the Java cert and keystore as per the old instructions https://dcm4che.atlassian.net/wiki/spaces/ee2/pages/2556078/Setting+up+DCM4CHEE+with+TLS+encryption

Thanks,
Paddy

from weasis-pacs-connector.

I have tried to implement Nginx revers proxy, too, to no avail, unfortunately. The main application dcm4chee-web3 works fine via a Nginx proxy, but those https://<host-name>:<nginx-port> in weasis-pacs-connector.properties didn't help. I have used the following locations in my nginx.conf:

/dcm4chee-web3/ pass to <local ip: http port>
/weasis/ pass to <local ip: http port>
/wado/ pass to <local ip: http port>
/weasis-pacs-coonector/ pass to <local ip: http port>

For some reasons, weasis or Nginx (still do not know which one) is trying to connect to:
http://<host-name>:57443/weasis-pacs-connector/viewer?upload=manifest
http not https
When I was trying to connect to the web app (dcm4chee-web3) via the PACS server https port (8443) bypassing a nginx proxy, I was able to load weasis and images, but in this case weasis application was working via nginx proxy. That means that weasis can work via proxy, but not when both, web app and weasis app connected via proxy. I have no clue why it doesn't work..

from weasis-pacs-connector.

Hi,

I don't think I ever got the /weasis-pacs-connector url to work over HTTPS with DCM4CHEE 2.18.3. Instead I'm focusing on trying to get the current version (dcm4chee-arc-light 5.x.x) to work.

Paddy

from weasis-pacs-connector.

We've already used https with dcm4chee 2.18.3 but not with nginx.

Focusing on dcm4chee-arc-light would be better.

from weasis-pacs-connector.

I was able to make it work with nginx, eventually. I am not sure, and it doesn't matter already, if this is a bug of dcm4chee-2.18.3, but that initial redirection to the weasis-pacs-connector (when an eye icon is being clicked) opens http connection and not just to port 80 but rather to the port in the client request. And my work around works only when nginx server (ssl termination) listens only on the port 443 (ssl hhtp2). That means that weasis-pacs-connector.properties must be modified accordingly. So I have just set up another server which listens on the port 80 (weasis-pacs-connector) and pass it to the right https server/location. Port 80, because when that initial request to the weasis-pacs-connector is sent it just changes https to http without port changing in it.

I was trying to use a nginx reverse proxy just to hide that obsolete JBoss 4.2.3 (which cannot be upgraded or patched) from those rogue hackers behind the powerfull and secure Nginx (which can be always updated/upgrade). If not Symantec on my Windows server, I would be hacked long time ago.

I do not know what you mean by focusing on dcm4chee-arc-light.

I have installed it and it works, but it is just a matter of time when this new dcm4chee will start to have security issues, like Wildfly, PostgreSQL upgrade.
I am not sure if it has it already, but suspect that it is going to happen very soon, like limitations on which version of the above mentioned application servers can be used and this is when those mean Internet guys will begin to exploit all those security vulnerabilities.

You can try metasploit, openVAS with dcm4chee-2, the results are depressive.

To expect from the open source (free) application that it will be rewritten to address those security issues?.... I am not so sure, it happened with dcm4chee-2 when JBoss 4.2.3/Java 7 was a requirement even for the latest 2.18.3.

So, if you mean focusing on nginx - dcm4chee-5 implementation, I agree with you and this is my next nginx project.

from weasis-pacs-connector.