Open bornemisza opened 3 years ago
Can you verify that the "B" repository hook from Github contains a X-Hub-Signature
header?
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
Interesting. I don't think anything has changed around that code lately. What version of webhook are you using?
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
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.
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.
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
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.
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.
I have the same problem. But I solved it. just follow step.
centos 8.2
[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
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
[
{
"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"
}
}
}
]
}
}
]
webhook -ip 127.0.0.1 -port 9600 -hotreload -hooks /data/auto-deploy/config.json -debug
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
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.
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.
2.6.9 still fails and 2.8.0 works (both with application/json
) for me. Something must have changed.
Seems like there were quite some changes in hook.go
that could have an impact.
2.7.0 also fails.
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
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?
@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.
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
Hello,
@howkymike could you please give a curl command sample that you use to execute the webhook with this configuration ?
Thanks Alain
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".
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:
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?