Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-68589

Provide sysprop option to disregard HTTP/HTTPS protocol when accepting webhooks

      In cases where Bitbucket is servicing requests behind a firewall, it may be identified by both a HTTP and HTTPS url. This bug requires creating the option to ignore the protocol when accepting webhooks so that webhooks served from a HTTPS Bitbucket are not treated by Jenkins as coming from a separate host.

      Original ticket:

      I've configured plugin and pipeline as described in tutorial all test connections from Jenkins side and Bitbucket side works well. I built pipeline successfully and status updated on Bitbucket server.

      When Bitbucket is sending request with webhook, it doesn't trigger my pipeline and I'm receiving a base URL not match info inside Jenkins logs.

      Jenkins has access through http to Bitbucket and Bitbucket base URL is https. Is it important?

          [JENKINS-68589] Provide sysprop option to disregard HTTP/HTTPS protocol when accepting webhooks

          Martin Henschke added a comment - - edited

          Hi Farshid, thanks for raising this ticket.
          Based on the information you've provided I suspect this is a configuration issue, but I need to know a bit more about your setup first. When you say Jenkins is using a HTTP url but your Bitbucket base URL is HTTPS, are you operating Bitbucket behind a load balancer, but using one of the HTTP nodes as your jenkins configured base URL?

          The fact that the protocols is different is probably less significant than that the URLs themselves are different. Our plugin accepts a webhook from an instance expecting the URL from which the request originates, and we use that to identify which server instances are applicable for a given job. If the URLs don't match, we assume different hosts and do not build.

          If it is possible to use the HTTPS url the webhook is originating from rather than the HTTP url, I expect this problem will be resolved unless there's a reason we can't use that URL- in which case could you let me know, and we can potentially open a feature request given your use case.

          Thanks,
          Martin

          Martin Henschke added a comment - - edited Hi Farshid, thanks for raising this ticket. Based on the information you've provided I suspect this is a configuration issue, but I need to know a bit more about your setup first. When you say Jenkins is using a HTTP url but your Bitbucket base URL is HTTPS, are you operating Bitbucket behind a load balancer, but using one of the HTTP nodes as your jenkins configured base URL? The fact that the protocols is different is probably less significant than that the URLs themselves are different. Our plugin accepts a webhook from an instance expecting the URL from which the request originates, and we use that to identify which server instances are applicable for a given job. If the URLs don't match, we assume different hosts and do not build. If it is possible to use the HTTPS url the webhook is originating from rather than the HTTP url, I expect this problem will be resolved unless there's a reason we can't use that URL- in which case could you let me know, and we can potentially open a feature request given your use case. Thanks, Martin

          Hi Martin,

          Thanks for your response. No I'm not using load balancer. We have a network infrastructure with a firewall, our Bitbucket server is accessible globally with HTTPS but duo to network configuration we should use it locally through HTTP and using HTTPS is not possible. So Jenkins and Bitbucket are seeing each other using HTTP. 

           

           

          Farshid Abdollahi added a comment - Hi Martin, Thanks for your response. No I'm not using load balancer. We have a network infrastructure with a firewall, our Bitbucket server is accessible globally with HTTPS but duo to network configuration we should use it locally through HTTP and using HTTPS is not possible. So Jenkins and Bitbucket are seeing each other using HTTP.     

          Thanks for explaining your use case

          This is a slightly tricky case. It's important to note that by having SSL configured, Bitbucket will be using HTTP address as it's_ base URL_. This is because Bitbucket is expecting all interactions to use this url- when users visit pages they will be using the HTTPS address, so REST, git, and webhook requests will always return and redirect to the HTTPS. Bypassing your SSL termination is working when configuring and triggering jobs because the URL you're using is valid, but Bitbucket is identifying itself using the HTTPS address. So it's not quite right to say Jenkins and Bitbucket are seeing each other through HTTP- they're talking through HTTP, but Bitbucket doesn't know that when sending a webhook.

          We use webhook URLs as identifiers for which job we wish to trigger, and if we remove this identification, we expose Jenkins to spoofing- anyone could send a webhook to Jenkins requesting a job be triggered.

          One possible solution to this issue is to disregard protocol when verifying webhook signatures- this is something we would only enable as a sysprop, and it would require that your Bitbucket HTTP and HTTPS URLs are identical except for the protocol. If this is the case, I'll update the ticket with the details.

          If the URLs are not identical, then as far as Jenkins is concerned, you're communicating with Bitbucket with two completely separate hosts, and I'm afraid that's not a use case we intend on supporting.

          Martin Henschke added a comment - Thanks for explaining your use case This is a slightly tricky case. It's important to note that by having SSL configured, Bitbucket will be using HTTP address as it's_ base URL_. This is because Bitbucket is expecting all interactions to use this url- when users visit pages they will be using the HTTPS address, so REST, git, and webhook requests will always return and redirect to the HTTPS. Bypassing your SSL termination is working when configuring and triggering jobs because the URL you're using is valid, but Bitbucket is identifying itself using the HTTPS address. So it's not quite right to say Jenkins and Bitbucket are seeing each other through HTTP- they're talking through HTTP, but Bitbucket doesn't know that when sending a webhook. We use webhook URLs as identifiers for which job we wish to trigger, and if we remove this identification, we expose Jenkins to spoofing- anyone could send a webhook to Jenkins requesting a job be triggered. One possible solution to this issue is to disregard protocol when verifying webhook signatures- this is something we would only enable as a sysprop, and it would require that your Bitbucket HTTP and HTTPS URLs are identical except for the protocol. If this is the case, I'll update the ticket with the details. If the URLs are not identical, then as far as Jenkins is concerned, you're communicating with Bitbucket with two completely separate hosts, and I'm afraid that's not a use case we intend on supporting.

          Thanks for your answer.

          Yes I understand. In our case Jenkins and Bitbucket are behind firewall and they're using HTTP locally so we don't have any security concern. 

          Right now Bitbucket HTTP and HTTPS URLs are idential. 

          Farshid Abdollahi added a comment - Thanks for your answer. Yes I understand. In our case Jenkins and Bitbucket are behind firewall and they're using HTTP locally so we don't have any security concern.  Right now Bitbucket HTTP and HTTPS URLs are idential. 

          Great, I'll update the ticket. Thanks Farshid!

          Martin Henschke added a comment - Great, I'll update the ticket. Thanks Farshid!

            Unassigned Unassigned
            farshid616 Farshid Abdollahi
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: