+++ extra.pipeline = "endpoints" template = "project.html" +++

Webhook endpoints

This repository contains documentation and tests about running webhook endpoints as part of a forge suite setup. There are tests for CLI webhook validation programs (such as whck), as well as for HTTP endpoints calling such webhook checkers. A certain number of conventions (environment variables and folder structure) should make it "just work" for different kinds of setups including shared hosts with unprivileged accounts. For setup information, please head over to the Setup section.

Below, you will find specifications for the CLI and Web programs. For the reference of supported webhook sources and their respective property, please read the Sources section

Command-line interface

A CLI webhook validator is a program that parses an identifier, a webhook body as well as a claimed secret provided by the caller, and attempts to validate the claim against the actual secret matching the provided identifier (if it was found). The following verification mechanisms are supported so far:

• hmac-sha256: used by Github and Gitea to sign the JSON payload
• token: used by Gitlab without signatures, so the body (payload) is ignored

The webhook validator uses the following syntax:

• whck KIND IDENTIFIER CLAIM (+ BODY as STDIN), where:
• KIND is a supported verification mechanism (hmac-sha256 or token)
• IDENTIFIER is the repository unique ID, usually a base16 or base64 encoding of the repo URL
• CLAIM is the claimed signature or secret token
• BODY is the actual HTTP body (usually a JSON payload), passed via STDIN

The webhook validator returns 0 when validation succeeded, or any other exit code if it fails. In the future, error codes could be standardized.

Conventions

In order to facilitate deployment in varied setups, the following conventions are respected:

• the secrets directory is generated from the following possibilities, in order of precedence:
  • from the WHCK_DIR environment variable (automated tests)
  • from the XDG_CONFIG_HOME environment variable, with "whck" appended (user operating CLI, or WWW running as user)
  • from the HOME environment variable, with ".config/whck" appended (user operating CLI, or WWW running as user)
  • from the current path to the executable, checking if it's inside a /home/ folder, and if so appending ".config/whck" (WWW running as system account, calling a symlink to a user-provided executable)
  • if all those discovery methods failed, the validator program fails to start and returns an error code
• each implementation contains a spec submodule containing this very repository (forge/endpoints)
• each implementation contains a test.sh executable script allowing to start the automated tests for this codebase, as explained in the next section ; the script should also check for the presence of the specs submodule and clone it if it was not already done
• each implementation contains a bin/cli executable script which will build the code and if it succeeds return a 0 exit code with the absolute path to the executable printed to STDOUT

Testing

If you want to run tests for an existing implementation, please run the test.sh script from the implementation's repository.

NOTE: Running tests requires the bats testing framework. You can usually find it in your distro repositories. If not, head over to the bats repository.

The test_cli.sh script is used for testing CLI webhook validators (such as whck). It takes as first positional argument a path to the repository to test (which contains a bin/cli script as explained above). If no repository is provided as argument, the following paths will be attempted, in order of precedence:

• ./, relative to the directory from which you called the tests (eg. if you're running ~/endpoints/specs/test_cli.sh from ~/whck repository)
• ../, relative to the directory containing test_cli.sh (eg. if you're running ./test_web.sh from specs submodule in whck repository, or from the main repository)
• if no path was matched, the test suite fails to start

To run tests, simply call ./test.sh from your implementation repository.

If you're making an implementation from scratch, you need to write your custom bin/cli script. Then, you can copy the test.sh script from whck and it should work.

Note: to test that the test suites can be called from several folders using different kind of relative/absolute paths, use the test_tests.sh script.: It will try the following paths, in order of precedence:

• the explicit path passed as first argument
• the current working dir (from which test_tests.sh is called), so you can for example call spec/test_tests.sh from the whck repository
• a temporary directory where whck will be cloned, and tests will be run against the latest commit

Web interface

Conventions

Testing

If you want to run tests for an existing implementation, please run the test.sh script from the implementation's repository.

NOTE: Running tests requires the bats testing framework. You can usually find it in your distro repositories. If not, head over to the bats repository.

Or you can call test_web.sh with an absolute path to a server starting script for an implementation

Setup

Now it gets tricky... In all cases you need some kind of shell account!

Unprivileged user, web server running as user

Unprivileged user, web server running as system account

Privileged user (requires root)