southerntofu
d07f677eab
Add a skeleton for web spec/testing info and for setup documentation |
||
---|---|---|
tests | ||
.gitignore | ||
README.md | ||
test_cli.sh | ||
test_tests.sh | ||
test_web.sh |
README.md
+++ 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 payloadtoken
: 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
ortoken
)IDENTIFIER
is the repository unique ID, usually a base16 or base64 encoding of the repo URLCLAIM
is the claimed signature or secret tokenBODY
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
- from the
- 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 thespecs
submodule and clone it if it was not already done - each implementation contains a
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 cli
script returning the (compiled) program to check. If no program is provided as argument, the following paths will be attempted, in order of precedence:
./cli
, relative to the directory from which you called the tests (eg. if you're runningspecs/test_cli.sh
from whck repository)../cli
, relative to the directory containing test_cli.sh (eg. if you're running./test_web.sh
from specs submodule in whck 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 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.:
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!