As there was an issues with the parser which checked the validity of
the JSON pointer pointing to the received JSON data this part is
removed. Further some checks were added to double check that case
which lead to an invalid behaviour.
This fixes#9.
In order to keep things together the code was restructured. Some small
improvements such as clippy warnings and the validation of a hook in
regards of the ip filter.
To support command line arguments `clap` is used. This adds following
argument `--config`/`-c` to provide a different path for the
configurationf file and the subcommand `configtest` which parses and
loads the configuration and exits.
This introduces thee so called conjunction filters and therefore
restructures the configuration file. The most obvious changes from an
users perspective are that the `filters` field was renamed to `filter`
and can, from now on, only support a single filter at first
level. Thats why now different filter types are implemented, please
consult the readme for further information on their usage.
To reflect the changes the readme file is updated as well as the
example config file contained in this repository.
This is related to #8
To be able to parse other values than
`serde_json::Value::String(String)` we parse the pointer parameters
and replace all those values in the JSON data with strings.
In order to allow or deny sources of requests the possibility to
configure a list of allowed or denied IP addresses was added as
described by the readme.
Closes#3
For better readability, correctness and maintainability the
body (which is still rather large, though) was restructured.
Regarding the signature, to be able to configure different fields in
the HTTP header the configuration parameter signature was added.
Instead of looking for a "secret" field hmac is used. Therefore the
raw payload is hashed with all secrets consecutively in order to
validate its content. If the content is certified the established
behaviour is pursued..
To create a minimalistic parser, nom is used to identify and replace
parameters given in the command field.
For clarity the `action` field for hooks was renamed to `command`.
In order to validate requests a field called `secret` has to be sent
containing a secret key which validates the request. A hook will be
executed only if the secret sent with the request matches the hook's
secret.
