http.nonProxyHosts has no effect, webhook delivery failing (CE 7.9.1 build 27448)

SonarQube
, ,
1

Hi- I’m having some difficulties with webhooks and proxy settings behind a corporate firewall.

Must-share information:

  • versions: SonarQube 7.9.1 (build 27448) on Linux
  • trying to achieve: webhook from SonarQube to Jenkins via HTTPS
  • tried so far: various combinations of proxyHost, proxyPort, and nonProxyHosts

The intent is to have SonarQube communicate to a Jenkins via webhooks (Administration > Configuration > Webhooks). The firewall is external only.

Scenario 1: no proxy information in sonar.properties

  • Jenkins pipeline initiates a Sonar scan
  • webhook from SonarQube to Jenkins is delivered correctly
  • no -D options have been set
  • Jenkins and SonarQube can communicate to each other, but external connectivity (Marketplace, Update Center) is compromised

Scenario 2: proxy host and port provided in sonar.properties

Scenario 3: proxy host, port, and nonProxyHosts provided in sonar.properties

Scenario 4: proxy host, port, and nonProxyHosts provided as -D JVM options for sonar.ce (and others)

Doing some research, I have found a closed item (https://jira.sonarsource.com/browse/SONAR-11251) which indicates some previous success with using the javaOpts which prompted Scenario 4 testing. There was also a community post about OkHttp3 not honoring the nonProxyHosts setting (WebhookCallerImpl (Okhttp3) doesn't honour http.nonProxyHosts) which is a bit older and I don’t know if this is still relevant.

The ce.log also does not seem to provide more detail despite the DEBUG log level being specified.

3

Hello @20nvmwp4,

Well done for all the testing. I think your Scenario 1 and 2 are enough to understand how to solve this.
If I summarize:

  • Without proxy, webhooks are fine but no Marketplace
  • With proxy, Marketplace is ok but webhooks aren’t

Internally, I’m quite sure you need the proxy for external connection (Marketplace), so you have to enable it (=> Scenario 2). From there you have 2 solutions to make webhooks works:

  • configure your proxy to let them go. Indeed if they fail, it’s because the proxy block this connection.
  • exclude the proxy use for this. The localhost|127.*|[::1] value into http.nonProxyHosts tells SQ to not use the proxy for loopback connections (ofc, this makes no sense, network-wise). But it doesn’t tell SQ to also not use it to connect to your Jenkins. This what you have to do.
    What’s you Jenkins IP? Let’s say 10.0.0.8 for example. Then put http.nonProxyHosts=localhost|127.*|[::1]|10.0.0.8 and SQ will directly send Webhooks to Jenkins, without using the Proxy (and it should work based on the scenario 1 results you gave).

Let me know how it goes!

Antoine

4

Hello Antoine,

Thanks for your reply- yes you have accurately described scenarios 1 and 2.

Scenarios 3 and 4 are essentially what you are describing, let me see if I can clarify:

Scenario 3 is where I have specified the proxy host/port (same as scenario 2) and nonProxyHosts in the sonar.properties file. In sonar.properties, I have put the following-

http.proxyHost=<hostname of our proxy, FQDN>
http.proxyPort=<port number>
http.nonProxyHosts="*.<our domain>|localhost|127.*|[::1]"

Scenario 4 uses only the JVM options, providing -Dhttp.proxyHost -Dhttp.proxyPort -Dhttp.nonProxyHosts, with the values above.

Frustratingly, neither of those worked either (as I reported in my original post).

I have instead, begun doing some time-intensive trial-and-error, arriving at this solution:

http.nonProxyHosts="<FQDN of Jenkins instance>|localhost|127.*|[::1]|*.<our domain>"

I am unsure why this was necessary in order for this to work- it seems this is in three blocks: the first must contain the FQDN of the Jenkins instance. The second block needs the "localhost|127.*|[::1]" loopbacks. The last block is the wildcard domain root. Removing any of those three “blocks” seems to result in the nonProxyHosts from not working.

My issue, is resolved, however, this does not align with my understanding of http.nonProxyHosts. With no further detail in logs it’s not possible to really see what’s happening- this doesn’t result in a stack trace or other visible failure, and if anything that’s something I’d like to see as a feature request.

Thank you.