test_SignatureCheck

Test runner to be able to run a number of tests (e.g. on a different val). check the references for seeing how it is used. It is extracted into a val to avoid having all that clutter in the same val as your tests. Each test is a named function (which can be async), the name is used as the name for the test. the input passed as the first argument is passed to each test, great for importing assertion methods, stubs, fixed values, ... everything that you do not mutate during a test if a function is async (it returns a promise) there is a timeout of 2 seconds before the test is marked as failed. all tests are called in the declared order, but async tests run in parallel afterwards, so don't assume any order if a test starts with skip it is not executed if a test fails it throws the output, so it appears in the read box below the val and the evaluation/run is marked red if all tests pass it returns the output, so it appears in the grey box and the evaluation/run is marked green. Note: If you are using the test runner to store the result in that val, as described above, it is considered a "JSON val" and has a run button, but it also means that another of your vals could update the val with just any other (JSON) state. Alternatively you can define a function val that calls the test runner and have a separete val to keep the curretn test results, but it means after updating the tests you need to fest save that val and then reevaluate to val storing the test state.

This val has been created to avoid certain shortcomings of @vtdocs.verifyGithubWebhookSignature . So it was created as a mix/evolution of two sources: The github docs about securing webhook Some code from the @octokit/webhhokmethods package This code is covered by tests which you can copy to run them, see @karfau.test_SignatureCheck This val does not contain any val.town specific code ( @ -imports, console.email ...), so it should be possible to run in Deno as is, potentially even in modern browsers (that support crypto and TextEncoder and modern ES syntax). Usage const myGithubWebhook = (req: Request) => { const {verify} = @karfau.SignatureCheck(); // you have to call it to get the verify function! const body = await req.text(); const signature = req.headers.get("X-Hub-Signature-256"); const verified = await verify( {payload:body, signature}, @me.secrets.myGithubWebhookSecret, // optionally provide fallback secrets (as many as needed) // @me.secrets.myGithubWebhookSecretFallback ); if (!verified) { return new Response(`Not verified`, 401); } const payload = JSON.parse(body); // actually do things in your webhook }; By default the reason for failing verification is logged to console.error , but you can pass it a different handler: const {verify} = @karfau.SignatureCheck((reason) => { throw new Error(reason); }); (be aware that it will silently fail if you don't try catch it in an endpoint and the return code will be 502) Why @vtdocs.verifyGithubWebhookSignature has the following issues: it relies on the verify method of the outdated @octokit/webhooks-methods@3.0.2 which has (at least) two bugs that can make a difference when used in a webhook it can throws errors instead of just returning false , which can be triggered by sending an invalid signature it can be lured into checking a SHA1 signature if the signature header starts with sha1= you need to pass the secret and payload as argument to the val, which makes them appear in the evaluation logs you produce ( they are only visible for the author of the val if you run them as an API , but it still feels odd to see the secret in the evaluation logs.) parameters are all of type string and the order can be confused you can not use fallback secrets for rotating