Receive webhooks and trigger actions based on them.
Go to file
finga d552e29e8f Build a Debian package
The first version `0.1.0-rc.0` and metadata for `cargo-deb` is now in
`Cargo.toml`. For that, the service file as well as the config file
were moved.

For a improved systemd service file the `User` and `Group` is now set
via variables and the log level is now set to `info`. In the previous
version of the service file the parameter for `ExecStart` was missing
which prevented this file from working.

The dependencies in `Cargo.lock` were updated.
2021-04-17 00:08:11 +02:00
debian Build a Debian package 2021-04-17 00:08:11 +02:00
src Fix execution of scripts 2021-04-17 00:04:22 +02:00
.gitignore Parse JSON from post request 2021-02-02 11:17:27 +01:00
Cargo.lock Build a Debian package 2021-04-17 00:08:11 +02:00
Cargo.toml Build a Debian package 2021-04-17 00:08:11 +02:00
config.yml Build a Debian package 2021-04-17 00:08:11 +02:00
README.md Split from_data() up in smaller pieces 2021-04-03 01:10:50 +02:00

Webhookey

Webhookey is a webserver listening for requests as for example sent by gitea's webhooks. Further, Webhookey allows you to specifiy rules which are matched against the data received to trigger certain actions.

Build

Install Rust

Install the Rust toolchain from rustup.rs.

Further, for Rocket we need to have the nightly toolchain installed:

    rustup toolchain install nightly

Build Webhookey

The webhookey project can be built for development:

    cargo b

or for releasing:

    cargo b --release

Install Webhookey

When a Rust toolchain installed you can also install Webhookey directly without cloning it manualy:

    cargo install --git https://git.onders.org/finga/webhookey.git webhookey

or from within the project:

    cargo install webhookey

Run Webhookey

Webhookey can either be run from the project directory with:

    cargo b

or you can copy the produced binary somewhere else from webhookey/target/{debug, release}/webhookey depending on which one you built.

Configuration

Configuration syntax is YAML and it's paths as well as it's configuration format is described in the following sections.

Configuration paths

Following locations are checked for a configuration file:

  • /etc/webhookey/config.yml
  • <config_dir>/webhookey/config.yml
  • ./config.yml

Whereas <config_dir> depends on the platform:

  • Linux: $XDG_CONFIG_HOME or $HOME/.config
  • macOS: $HOME/Library/Application Support
  • Windows: {FOLDERID_RoamingAppData}

Configuration parameters

Hooks

With hooks you can configure a sequence of hooks. A single hook consists of the following fields:

  • command: A command to be executed if a filter matches
  • allow/deny: An optional parameter to either allow or deny specific source addresses or ranges.
  • signature: Name of the HTTP header field containing the signature.
  • secrets: List of secrets.
  • filters: List of filters.

Example:

hooks:
  hook1:
    command: /usr/bin/local/script_xy.sh {{ /repository/name }}
    signature: X-Gitea-Signature
    ip_filter:
      allow:
        - 127.0.0.1
        - 127.0.0.1/31
    secrets:
      - secret_key_01
      - secret_key_02
    filters:
      match_ref:
        pointer: /ref
        regex: refs/heads/master
Command

To pass data to a command following two different methods can be used.

Example: script_foo {{ header X-Gitea-Event }} {{ /field/foo }}

JSON Pointers

Use JSON pointers (RFC 6901) point to values of a JSON field from the JSON data.

Example: {{ /field/pointed/to }}.

Header

Use values from header fields sent with the HTTP request.

Example: {{ header X-Gitea-Event }}.

Allow and Deny

To allow or deny specific network ranges source is an optional configuration parameter which either contains an allow or a deny field with sequences containing networks. Note that IPv6 addresses have to be put in single quotes due to the colons.

Example:

allow:
  - 127.0.0.1
  - 127.0.0.1/31
  - "::1"
deny:
  - 127.0.0.1
  - 127.0.0.1/31
  - "::1"
Signature

Set the name of the HTTP header field containing the HMAC signature.

Secrets

Configure a list of secrets to validate the hook.

Filter

Each filter must have following fields:

  • pointer: pointer to the JSON field according to RFC 6901
  • regex: regular expression which has to match the field pointed to by the pointer

TODOs

Use clap to parse command line arguments

Configure rocket via config.yml

Security

https support

basically supported, but related to "Configure rocket via config.yml".

Authentication features

Use proptest or quickcheck for tests of parsers