Webhook-Server

这个小助手的作用很简单：在服务器上执行http请求。最初，它被设计用于持续集成，并支持开箱即用的GitHub的webhooks。

现在，Webhook-Server还附带了一个自定义调度器。默认情况下，调度器防止并行部署和不必要的部署执行。但是，如果您想要排队许多并行负载重和长时间运行的任务，它允许您指定每种类型的并发任务数量，以防止系统过载。任务可以并行处理或逐个处理，执行模式和并行进程的数量可以按webhook类型配置。

示例应用

• 项目的持续集成（支持GitHub的webhooks）。
• 按需执行并行负载重任务。
• 通过浏览器在您的服务器上触发任务。
• 使用最小设置在服务器之间触发任务。

查看示例配置文件 webhook_server.yml。

安装

Arch Linux
只需使用任何包管理器安装，例如 yay -S webhook-server-git。

发布
每个发布都包含为Linux、Mac和Windows预构建的二进制文件。您可以在项目的 releases 标签中找到它们。

手动安装

git clone https://github.com/nukesor/webhook-server
cd webhook-server
cargo install --path .

您的 $CARGO_HOME/bin 文件夹应位于您的 $PATH 中。

配置

Webhook-Server通过以下顺序的文件进行配置

• /etc/webhook_server.yml
• ~/.config/webhook_server.yml
• ./webhook_server.yml

较高级别配置文件的配置值会覆盖较低级别配置文件的配置值。例如，/etc/webhook_server.yml 中的值可以被 ~/.config/webhook_server.yml 覆盖。

Mac-OS

• ~/库/应用程序支持/webhook_server.yml
• ~/Library/Preferences/webhook_server.yml
• ./webhook_server.yml

Windows

• $APPDATA$\Roaming\webhook_server\webhook_server.yml
• .\webhook_server.yml

配置值

• domain (127.0.0.1) 服务器应监听的域名
• port (8000) 服务器应监听的端口号
• ssl_private_key (null) SSL私钥路径。服务器将使用其自身的SSL证书。如果您不使用已经使用SSL的代理网络服务器，则建议使用。强烈建议使用任何类型的SSL，尤其是如果您公开暴露了您的端点。
• ssl_cert_chain (null) SSL证书路径。SSL设置也需要此信息。
• workers (4) 并行处理webhook的worker数量。如果您计划处理大量请求或触发长时间运行的任务，请增加worker的数量。
• basic_auth_user (null) 如果您想进行基本认证，请提供您的用户名。有关基本认证头部的更多信息，请参阅构建请求部分。
• basic_auth_password (null) 如果您想进行基本认证，请提供您的密码。
• secret (null) 用于通过负载签名验证进行认证的秘密。有关签名头部的更多信息，请参阅构建请求部分。例如，可以使用pwgen 25 1创建。
• basic_auth_and_secret (false) 默认情况下，只需要通过BasicAuth或签名认证进行认证。如果您想非常安全，请将其设置为true，以要求两者。
• webhooks webhook列表。整个结构看起来大致如下

webhooks:
  -
    name: 'ls'
    command: '/bin/ls {{param1}} {{param2}}'
    cwd: '/home/user'

Webhook配置值

• name webhook的名称，也是用于触发webhook的端点。例如：localhost:8000/ls。
• command 实际使用的命令。如果您想动态构建命令，可以使用模板参数，例如{{参数名称}}。
• cwd 命令应从中执行的当前工作目录。
• mode (deploy) 确定命令应执行的模式。
  1. deploy 至多一个排队和一个正在运行。这是默认值。
  2. single 每个webhook类型最多一个排队或正在运行的项目
  3. parallel 无限制排队，默认最大4个并行任务。此数字可以调整。
• parallel_processes (4) 在parallel模式下运行的并行任务的最大数量。

其他文件

在存储库的misc文件夹中有一些模板文件供您设置。这些包括

• A nginx代理路由示例
• A systemd服务文件

如果您有任何可能对他人有用的其他内容，请随时创建PR。

Github Webhook设置

前往您的项目设置选项卡并选择webhooks。创建一个新的webhook并设置以下选项

• 内容类型：Json
• 密钥：与您的配置中的字符串相同
• 启用SSL验证：如果您有SSL，则建议启用
• 仅推送事件（负载本身不使用）

您可以通过点击Recent Deliveries重新发送任何已发送的webhook，以便在您想要调试设置的情况下。

构建请求

Webhook服务器接受JSON POST请求和简单的GET请求。

这是一个使用httpie和密钥72558847d57c22a2f19d711537cdc446以及test:testtest基本认证凭据发布的示例POST请求

echo -n '{"parameters":{"param1":"-al","param2":"/tmp"}}' | http POST localhost:8000/ls \
        Signature:'sha1=d762407ca7fb309dfbeb73c080caf6394751f0a4' \
        Authorization:'Basic dGVzdDp0ZXN0dGVzdA=='

如果您不需要模板，您可以发送一个简单的GET请求

http GET localhost:8000/ls Authorization:'Basic dGVzdDp0ZXN0dGVzdA=='

负载

负载是一个简单的JSON对象，包含单个条目parameters。该对象包含渲染模板所需的所有参数。如果不需要模板，您可以提供空对象作为负载，或者直接通过GET调用路由。

例如，命令'/bin/ls {{param1}}}{{param2}}'的负载可能如下所示

{
    "parameters": {
        "param1": "-al",
        "param2": "/tmp"
    }
}

这将导致服务器执行ls -al /tmp。

头部

• Authorization：如果指定了basic_auth_username和basic_auth_password，则此应为标准的Basic base64编码的授权头。 基本认证指南
• Signature:如果您指定了一个密钥，则签名的内容是使用UTF8编码的密钥作为密钥的HMAC的JSON负载。此过程基于Github的webhook密钥系统。（Github告诉您使用十六进制密钥，但他们将其解释为UTF8 -.-）
  Python示例：hmac.new(key, payload, hashlib.sha1)
  Ruby示例：OpenSSL::HMAC.hexdigest("SHA1", key, payload)
  Github指南
• X-Hub-Signature：如果没有指定Signature，则此头部将用于签名检查（以支持Github的webhooks）。

查询当前状态

您可以通过查询服务器的根（/）来获取webhook调度程序当前状态和已完成任务的当前状态。这将为您提供一个包含有关现在正在进行的几乎所有事情信息的JSON响应。

要访问路由，请通过Basic身份验证。如果没有指定Basic身份验证，但存在秘密，则将使用空体的秘密。如果根本未使用身份验证，则任何人都可以查询状态。请使用某种身份验证。

安全性

代码注入：当使用模板编译动态命令时，您会暴露于代码注入风险，因为编译后的命令由系统shell执行。如果您计划使用模板并公开您的服务，请使用某种身份验证。

1. 您可以使用秘密来使用签名验证有效载荷（GitHub的认证方法）。无论如何，如果您自己实现，这种方法可能会有点麻烦。
2. 您可以使用基本认证。
3. 如果您想非常安全，可以要求两种认证方法。

SSL：特别是在使用基本认证或模板时，强烈建议使用SSL加密。这可以由您的代理Web服务器（nginx、apache、caddy）或直接在应用程序中完成。否则，您的凭据或模板有效载荷可能会泄露给任何监听的人。

创建示例证书和密钥的方法如下：openssl req -nodes -new -x509 -keyout test.pem -out test.pem。
如果您需要为私钥输入密码，请创建一个issue或PR（非常感谢）。