Jenkins reverse-proxy cant receive webhooks request (bitbucket+cloudflare)

francislavoie · November 8, 2023, 7:56am

Looking up the error message:

jenkinsci/bitbucket-plugin/blob/66d1a0fcba8f437fa3f3bbef52e5065f57332eb5/src/main/java/com/cloudbees/jenkins/plugins/BitbucketHookReceiver.java#L56


      
                      if (contentType != null && contentType.startsWith("application/x-www-form-urlencoded")) {
                          body = URLDecoder.decode(body);
                      }
                      if (body.startsWith("payload=")) body = body.substring(8);
          
                      LOGGER.log(Level.FINE, "Received commit hook notification : {0}", body);
                      JSONObject payload = JSONObject.fromObject(body);
          
                      payloadProcessor.processPayload(payload, req);
                  } else {
                      LOGGER.log(Level.WARNING, "The Jenkins job cannot be triggered. You might not have configured correctly the WebHook on BitBucket with the last slash `http://<JENKINS-URL>/bitbucket-hook/` or a 'Test connection' invocation of the hook was triggered.");
                  }
          
              }
          
              private static final Logger LOGGER = Logger.getLogger(BitbucketHookReceiver.class.getName());
          }

I think this is simply because the body was empty.

A successful request had:

And the one with a warning was lacking the Content-Length header.

I don’t think this is a Caddy config problem.

And to be clear, trusted_proxies only affects X-Forwarded-* headers, that’s all. It doesn’t affect anything related to the request body. It’s not relevant to the problem you’re seeing.

That said, a few suggestions:

I recommend also adding - "80:80" and - "443:443/udp" for HTTP and HTTP/3 respectively. Port 80 will redirect HTTP requests to HTTPS, and allow solving the ACME HTTP challenge, which is good for reliability in production.

I recommend moving your trusted_proxies to global options instead, it has multiple advantages over configuring it in reverse_proxy. See Global options (Caddyfile) — Caddy Documentation.

Also since you’re using Cloudflare, you could use the GitHub - WeidiDeng/caddy-cloudflare-ip plugin instead of specifying the IP ranges in your config, that plugin will keep the list up to date automatically. Does mean you need to use a Dockerfile to build Caddy, but that’s very simple.