26d6273f60
The catalog could POST to Discord and to Teams, and to nothing else: every other receiver needed its own package. This is the generic one — the destination is instance config, the body is the command's. Four senders and a test: post_json a JSON document, the receiver defines the schema send_event a normalised Riposte envelope (id, title, severity, link) post_form x-www-form-urlencoded, for receivers older than JSON webhooks post_raw a body verbatim with the Content-Type you choose Three decisions worth naming: - The destination is pinned on the instance and a per-call `url` is refused unless allow_url_override is set. An integration that always took its URL from the command inputs would be an arbitrary HTTP client for anything that can call it, the agent included. The SSRF guard (public addresses only, https only) sits behind the same kind of explicit opt-in. - `url` is sensitive. Slack, Teams, Discord, Zapier and n8n all carry the token in the path, so command output echoes scheme://host and never the path or the query. - test_connection opens a TCP/TLS connection and sends nothing. The health checker runs it on a schedule on every enabled instance; a receiver should not have to filter a Riposte ping every few minutes to keep one green. test_sends_ping opts into the real POST. Optional HMAC-SHA256 over the body (or over `<ts>.<body>`, the replay- resistant scheme Slack and Stripe use) lets the receiver prove the call came from Riposte. Retries cover 408/425/429/5xx and connection failures, honour Retry-After, and stay inside the sandbox's 60s ceiling. A non-2xx that survives them fails the command, so a playbook block never reports a delivery that did not happen. Verified against a local receiver: 52 checks over payload shapes, the three auth modes, both signature schemes, header precedence, retry and give-up, every guard, path/method handling, and both test modes.