Proxy configuration for addons

Hello,

A user of my OpenMeteo binding filled an issue asking for proxy support when connecting to the online service and I replied that because I use HttpUtil.downloadData then everything should be handled because it reads system properties like http.proxyHost and http.proxyPort.

The first issue I had answering this is that I have no idea where those are configurable in MainUI

And the second issue is that while there is a http.nonProxyHosts system property, the user would really prefer to have an “include list” for hosts that must be proxyied. Is this at all possible?

I doubt they are configurable in MainUI. Those are most likely settings that apply to the whole JVM, that must/should be set as start arguments to the JVM itself.

Perhaps it would work to simply set those as environment variables before starting OH, it depends on the details of how this works on Java’s side.

I doubt that you will find a way to do this through the UI, and I also doubt that you’ll find a “proxy include list”. Normally, proxies are applied universally, so that all traffic go through them. The exception list probably exists because some services just won’t work with a proxy.

I would question what the user is trying to achieve. A proxy is primarily meant as a cache that limits unnecessary external calls, and used to be much more relevant (and widely used) back when connections were much slower. It sounds like the user is trying to achieve something else, some form of anonymization of spoofing or similar. I’m not sure using a proxy like that is a viable path.

You shouldn’t modify the binding so that it can set these properties, because they should not be changed while the JVM is running. As with all system properties, changing them isn’t thread-safe, and will affect all kind of other things so that the implications are impossible to predict.

If there is some special need for this binding, you could manually control proxy for the binding specifically:

https://www.baeldung.com/java-connect-via-proxy-server

Well, they explain it here: SOCKS proxy support for API requests · Issue #7 · obones/openhab-binding-openmeteo · GitHub
Basically, they have issues with direct connection but they appear to have better luck with doing through a proxy.

Well, yes, but then what’s the point of HttpUtil if all binding developers must reimplement it in their own code?

downloadData is using global proxy settings
But you have a version of executeUrl for which you can provide any proxy setting.

Here is the method retrieving the default proxy settings using System.getProperty(

There is no version of downloadData for which you can provide specific proxy settings but could be added.

It would indeed be nice, but in the meantime, thanks for pointing out that executeUrl method, it’s a good candidate as it already existed in OH4 for which I have to keep compatibility

That sounds like a dirty workaround for a network problem to me. There’s no reason why a proxy, or a tunnel like here, would work better than a direct connection, unless is “tunnels through” network problems that would otherwise disrupt parts of the communication. Normally, all kind of proxy use just adds problem, and a direct connection is the most stable, straight forward solution.

That’s why I asked if there was a special need for this binding. If “all” bindings need to, it wouldn’t make sense, but as I said before, proxy isn’t used much these days, and if it’s used, you typically apply it to all traffic.

This use case, is a workaround for another problem, which is why it doesn’t exist in HttpUtil, and why Java itself has no “whitelist” for destinations that should be proxied.

I don’t know the user’s setup, but if this was me, and there was a “genuine need” (as opposed to a workaound for another problem), I would use the firewall to route traffic from a certain address (OH) to certain addresses (API endpoints) through a tunnel or through a different route etc.

Ah actually no, it won’t help because executeUrl returns a String when I specifically use downloadData to retrieve binary content.