shadcn.io is not affiliated with official shadcn/ui
Webhook Signatures Account Block for Vue
Check that a webhook came from the service: pick one of five deliveries, read its payload in a JSON tree and its signature header, and press Check signature to compute a real HMAC-SHA256 in the browser.
Installation
Overview
Teach people to trust a webhook only after they have checked it, with this signature check for Vue with Ark UI. A hairline frame with a plus mark on each corner splits into a list and a detail. At the start are the last five deliveries, each with its event, when it was sent and a badge for how it ended, one of them failed with a 500; at the end is the chosen one: its payload in a JSON Tree View, the signature header it was sent with in mono next to a Copy Button, a Switch that changes one character of the payload, and the Shine Button Check signature. Pressing it really computes an HMAC-SHA256 of the timestamp, a dot and the payload with the demo secret, in this tab with crypto.subtle, and writes "Matches" or "Does not match" with the signature that was sent and the one computed side by side. Turn the switch on and the same check fails. Nothing is sent anywhere. It's built from JSON Tree View, Switch, Copy Button, Badge, Shine Button and Guides, with a CSS entrance only. For the webhooks page of any service that signs its events.
FAQ
How do I fill it with my deliveries?
Edit DELIVERIES. Each has the event, the ISO time at, the status your endpoint answered, the stamp (the Unix time it was signed at), the body (the exact compact JSON text that was signed, kept as a string so no tool reorders its keys) and the sig your service sent. from and to are the text the tamper switch finds and what it turns it into. The demo SECRET is the signing secret for the endpoint; a real one is shown once and kept in a vault, never in the page.
Is the signature check real?
Yes. Check signature calls the browser's crypto.subtle: it imports the secret as an HMAC key, signs <timestamp>.<payload> with SHA-256 and compares the hex with the v1 value in the header. The five signatures were made the same way, so an untouched delivery matches and a changed one does not. It runs in this tab and nothing leaves it. The browser only offers crypto.subtle on https pages and localhost, and the block says so ("Could not compute") if it is missing.
What does the switch do?
It changes one character of the payload, for example success becomes successs, and shows the changed payload in the tree and the change in mono under the buttons. Checking then fails, which is the point: a receiver that skips the check would accept it. Turning it off or choosing another delivery clears the last result, so a "Matches" never stays next to a payload it was not computed for.
How do I verify for real in my endpoint?
Read the raw request body before you parse it, take the t and v1 values from the header, compute the same HMAC over t.body with your secret, compare in constant time and reject timestamps that are too old. Parsing the JSON first and signing it again can change the text and break the match, which is why this page keeps the body as the exact string that was signed.
How does it look on a phone?
The list comes first and the detail follows it: the payload in a scrolling frame of fixed height, the header with its copy button, the switch and the button, then the result in a box that keeps its height from the first state. The deliveries are buttons in a list, the chosen one is marked current, and the panel's foot is a polite live region that says what was checked.
Is it accessible?
The deliveries are real buttons with the chosen one marked aria-current, the payload frame is a labelled, focusable region, the switch is named "Change one character of the payload", the result is written out as words and values (never colour alone), and the status line speaks the verdict once ("evt_5k2m: matches."). Event names, times and signatures keep their order in a right-to-left page.