Webhook records are a way to associate a URL with some automatic execution of an AUX. The AUX could be hosted as a file record, or it could be in a data record, or it could even be an inst record.
Webhooks have these key things about them:
An endpoint. This is the URL location that needs to be hit with HTTP in order for the webhook to be called.
A target. This is the code that should be executed when the webhook is called. It can be link to a file record, data record, or private inst. The calling convention is to make a shout @onWebhook that contains the request parameters.
(optional) A sessionKey and optionally a connectionKey. These are used to authenticate the webhook to other CasualOS resources.
A list of markers. These determine who is able to create, trigger, and update webhooks. If a webhook record has publicRead, then anyone is able to make HTTP requests to the webhook. Otherwise, users have to include their session key in the request. When this happens, we need to be careful to not pass the user's actual session key along to the webhook code.
(optional) A name. Naming the webhook will allow for easier organization and also make it possible for users to call them by name directly.
(optional) An input schema. This will allow the webhook to automatically validate its inputs and also support automatic documentation generation in the future.
It should be noted that the architecture of webhooks is that there is a separate "execution engine" that is able to perform arbitrary shouts into execution targets (like file records, data records, insts, etc.). This execution engine can ideally run in contexts with zero permissions (i.e. separate lambda or EC2) and uses Deno as the aux-vm. For now, each execution will get its own Deno process and have a configurable timeout. When a webhook is received, the parameters can be resolved by the server and sent to the engine for execution. After results have been produced, then the webhook can be completed.
Additionally, the following should be noted:
Deployments that enable Privo features should have Webhook features disabled until we perform a "Best Interests of the Child" evaluation.
Webhook records are a way to associate a URL with some automatic execution of an AUX. The AUX could be hosted as a file record, or it could be in a data record, or it could even be an inst record.
Webhooks have these key things about them:
@onWebhookthat contains the request parameters.publicRead, then anyone is able to make HTTP requests to the webhook. Otherwise, users have to include their session key in the request. When this happens, we need to be careful to not pass the user's actual session key along to the webhook code.It should be noted that the architecture of webhooks is that there is a separate "execution engine" that is able to perform arbitrary shouts into execution targets (like file records, data records, insts, etc.). This execution engine can ideally run in contexts with zero permissions (i.e. separate lambda or EC2) and uses Deno as the aux-vm. For now, each execution will get its own Deno process and have a configurable timeout. When a webhook is received, the parameters can be resolved by the server and sent to the engine for execution. After results have been produced, then the webhook can be completed.
Additionally, the following should be noted: