Improve Documentation of Proxy Settings

[haemka]

After upgrading DSF to 0.9.0 and the CODEX processes to 0.7.0 as described in the upgrade guide and whitelisting all required domains and hosts in our outbound proxy, the request for terminology-highmed.medic.medfak.uni-koeln.de hits our firewall instead of going through the proxy.

We configured our outbound proxy for the BPE container via ORG_HIGHMED_DSF_BPE_FHIR_CLIENT_LOCAL_PROXY_URL as described in the documentation.

[hhund]

Hi @haemka ,

the documentation for ORG_HIGHMED_DSF_BPE_FHIR_CLIENT_LOCAL_PROXY_URL is a bit imprecise.

Instead of:

set if the DSF BPE server can reach internal servers, like the DSF FHIR server, only through a proxy

it should say:

set if the DSF BPE server can reach the local DSF FHIR server, only through a proxy

To configure a proxy server for the connection to the terminology server use the specific environment variable from the NUM-CODEX process plugin:

DE_NETZWERK_UNIVERSITAETSMEDIZIN_CODEX_GECCO_VALIDATION_VALUESET_EXPANSION_CLIENT_PROXY_SCHEMEHOSTPORT

[haemka]

Thanks. That seemed to work. But now we are hitting the firewall with the next URL: packages.simplifier.net:443 [packages.simplifier.net/40.68.205.178]

Until now we got our proxy defined three times:

• ORG_HIGHMED_DSF_BPE_FHIR_CLIENT_REMOTE_PROXY_URL
• DE_NETZWERK_UNIVERSITAETSMEDIZIN_CODEX_FTTP_PROXY_URL
• DE_NETZWERK_UNIVERSITAETSMEDIZIN_CODEX_GECCO_VALIDATION_VALUESET_EXPANSION_CLIENT_PROXY_SCHEMEHOSTPORT

Why isn't there single configuration for all external communication?

This is really tedious especially since the installation and update documentations leaves us pretty much in the dark here and just requests us to look at the process parameters which are just documented in overwhelming lists with ambiguous descriptions.

[hhund]

The proxy configuration for downloading FHIR packages by the NUM-CODEX process plugin can be configured with:
DE_NETZWERK_UNIVERSITAETSMEDIZIN_CODEX_GECCO_VALIDATION_PACKAGE_CLIENT_PROXY_SCHEMEHOSTPORT

Having a proxy configuration for every connection was a conscious defensive decision. From the DSFs perspective we don't know what kind of connections process plugins will introduce and since there is great heterogeneity in network configurations the alternative would have been to use a single proxy config and introduce a "no proxy" list, thus increasing the risk of unintentional data leakage.

I'm sure the documentation can be improved. I'll leave this issue open and change the title, so that others aren't confused.