adnanh / webhook

webhook is a lightweight incoming webhook server to run shell commands
MIT License
10.08k stars 812 forks source link

Github - Hook rules were not satisfied. #524

Open bornemisza opened 3 years ago

bornemisza commented 3 years ago

We ran into an interesting problem and we found very hardly the "solution". I'm not sure about should we create a discussion instead of an issue?

We configured a webhook, which worked fine from the test account (Github, "A" private repository). After we checked everything, we switched to the live account (Github, "B" private repository, same configuration for the Github Webhooks) and got the Hook rules were not satisfied error. On both repository had "main" branch, got the push event and hooks did not worked from the live account on "B" repository. The configuration and the solution below:

Github: Payload URL: https://sitename.tld/hooks/sitename Content type: application/json Secret: password SSL verification: Enable Which events...: Just the push event

/etc/webhook.conf:

[ 
  {
    "id": "sitename",
    "execute-command": "/var/scripts/deploy/sitename.sh",
    "include-command-output-in-response": false,
    "trigger-rule": {
      "and": [
        {
          "match": {
            "type": "payload-hash-sha1",
            "secret": "password",
            "parameter": {
              "source": "header",
              "name": "X-Hub-Signature"
            }
          }
        },
        {
          "match": {
            "type": "value",
            "value": "refs/heads/main",
            "parameter": {
              "source": "payload",
              "name": "ref"
            }
          }
        }
      ]
    }
  }
]

We were not able to understand - what did we do wrong? where is the problem and what is the difference between "A" and "B" repository? Started to read the Github Webhooks docs and it says:

Note: For backward-compatibility, we also include the X-Hub-Signature header that is generated using the SHA-1 hash function. If possible, we recommend that you use the X-Hub-Signature-256 header for improved security. The example below demonstrates using the X-Hub-Signature-256 header.

So, we changed the hashing: "type": "payload-hash-sha1", => "type": "payload-hash-sha256", "name": "X-Hub-Signature" => "name": "X-Hub-Signature-256"

and our problem instantly solved, we are not getting the "Hook rules were not satisfied." error anymore.

After lot of painful hours we are happy that the problem is solved, but we would like to help the community to not waste more time like we did.

So still the question: where is the catch?

moorereason commented 3 years ago

Can you verify that the "B" repository hook from Github contains a X-Hub-Signature header?

bornemisza commented 3 years ago

Can you verify that the "B" repository hook from Github contains a X-Hub-Signature header?

Yes, the header contains the X-Hub-Signature. We checked that too previously when we compared the repositories and all the requests and responses

moorereason commented 3 years ago

Interesting. I don't think anything has changed around that code lately. What version of webhook are you using?

bornemisza commented 3 years ago

Interesting. I don't think anything has changed around that code lately. What version of webhook are you using?

v2.6.9 on ubuntu 20.04

ps.: https://packages.ubuntu.com/focal/webhook

moorereason commented 3 years ago

I can't think of why this wouldn't be working. If you're able to test the latest release, I'd like to know if it behaves differently. There should be a -debug flag in the newer versions that may provide more clues.

bornemisza commented 3 years ago

I can't think of why this wouldn't be working. If you're able to test the latest release, I'd like to know if it behaves differently. There should be a -debug flag in the newer versions that may provide more clues.

Sure, if you can ship newer version to ubuntu source package.

robhenley commented 3 years ago

I couldn't make 2.6.9 work either. What eventually did work was upgrading to 2.8.0 (via snap) and then using payload-hmac-sha256 with X-Hub-Signature-256 and being sure that the webhook was using a content type of application/json.

The debug logged the following prior to me finally making it work (again this was 2.8.0):

[webhook] 2021/05/22 18:56:21 [5dd745] deploy-test got matched
[webhook] 2021/05/22 18:56:21 [5dd745] parameter node not found: ref
hacklschorsch commented 3 years ago

I also couldn't make 2.6.9 (the version in current debian stable) work with either sha-1 or sha-256 with GitHub.

After wrestling with this for a couple of hours I removed the authentication altogether since this is a private (as in: my personal homepage) project in a private (as in: hidden) git hub repo. Still, uncool 🦕

Subscribing to this issue since hooking up GitHub to whatever is basically my only use case for webhook.

falcon03 commented 3 years ago

I am aving the same issue. Double-checked my hooks file, the request-headers, and unfortunately webhook does not work :(

I am using debian-packaged versioon 2.6.9 of webhook.

soonio commented 3 years ago

I have the same problem. But I solved it. just follow step.

0 env

centos 8.2

1 setting

[github -> Webhooks / Manage webhook - settings] Payload URL->https://hook.domain.com/hooks/{id-in-config.json} Content type->application/json Secret-> a-secret-string SSL verification->Enable SSL verification
Which events would you like to trigger this webhook?->Just the push event. check->Active

2 download

curl -SL https://github.com/adnanh/webhook/releases/download/2.8.0/webhook-linux-amd64.tar.gz -o webhook.tar.gz \
&& tar -xf webhook.tar.gz -C /usr/local/bin/ --strip-components=1 \
&& chmod +x /usr/local/bin/webhook

3 config.json

[
  {
    "id": "www",
    "execute-command": "/data/auto-deploy/www.sh",
    "command-working-directory": "/data/web",
    "http-methods": ["POST"],
    "pass-arguments-to-command":
    [
      {
        "source": "payload",
        "name": "head_commit.id"
      },
      {
        "source": "payload",
        "name": "pusher.name"
      },
      {
        "source": "payload",
        "name": "pusher.email"
      }
    ],
    "trigger-rule": {
      "and": [
        {
          "match": {
            "type": "payload-hmac-sha1",
            "secret": "a-secret-string",
            "parameter":
            {
              "source": "header",
              "name": "X-Hub-Signature"
            }
          }
        },
        {
          "match": {
            "type": "value",
            "value": "refs/heads/main",
            "parameter": {
              "source": "payload",
              "name": "ref"
            }
          }
        }
      ]
    }
  }
]

4 start

webhook -ip 127.0.0.1 -port 9600 -hotreload -hooks /data/auto-deploy/config.json -debug

5 nginx


server {
    listen 80;
    server_name  hook.domain.com;
    rewrite ^(.*)$ https://$host$1 permanent;
}
server {
    listen       443 ssl;
    server_name hook.domain.com;

    ssl_certificate  cert/hook.domain.com_bundle.crt;
    ssl_certificate_key  cert/hook.domain.com.key;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://127.0.0.1:9600/;
    }
}

## 6 
[githu Webhooks / Manage webhook -> recent Deliveries ]
click [redelivery] to try again and will success
falcon03 commented 2 years ago

yeah, looks like running the latest version solves the issue; however, I do not feel confortable installing webhook this way on my production server for security reasons, i.e. missing automatic security updates.

shawnz commented 2 years ago

Thanks @robhenley, as you suggested the issue for me was that I had to change the webhook content type from the default "application/x-www-form-urlencoded" to "application/json" in GitHub settings. With this change it works for me even on the old 2.6.9 version.

tcurdt commented 2 years ago

2.6.9 still fails and 2.8.0 works (both with application/json) for me. Something must have changed.

tcurdt commented 2 years ago

Seems like there were quite some changes in hook.go that could have an impact.

tcurdt commented 2 years ago

2.7.0 also fails.

howkymike commented 2 years ago

After over a year, there is still the same problem with the ubuntu distributed webhook (v. 2.6.9)... So far, the best solution I found is to install it via the snap (v. 2.8.0). snap install webhook

shawnz commented 2 years ago

To be clear you made sure you were using content type "application/json" in GitHub settings and also changed to use the "type": "payload-hash-sha256" and "name": "X-Hub-Signature-256" as described above, and even after both those changes it still doesn't work for you on 2.6.9?

howkymike commented 2 years ago

@shawnz That's correct. config:

"match":
          {
            "type": "payload-hmac-sha256",
            "secret": "****",
            "parameter":
            {
              "source": "header",
              "name": "X-Hub-Signature-256"
            }
          }

I'm on Ubuntu 20.04.3 LTS While using webhook from snapd (2.8.0) it works, while using webhood from apt (2.6.9) it does not.

nyngwang commented 2 years ago

FYI: you might need to open the port you assigned for the webhook for connection. Some refs:

# check port in use
sudo lsof -i -P -n | grep LISTEN
# open port
sudo ufw allow from any to any port $YOUR_PORT proto tcp
apellegr06 commented 1 year ago

Hello,

@howkymike could you please give a curl command sample that you use to execute the webhook with this configuration ?

Thanks Alain

howkymike commented 1 year ago

Hi @apellegr06 I do not use the cURL command, I have configured Webhooks directly in GitHub. You only have to change "Payload URL" and "Content type".