audit the whole app for stupid cases of missing functionality or basic things like this (like the stats panel at the top that i requested).
What is missing: the receiver stores each event's complete request headers and the entrypoint it arrived at (Event.Headers and Event.EntrypointID), but no page shows either. The event log shows only the method, event ID, content type and body; eventLogColumns in internal/handlers/event_log_view.go does not even load the other two.
So when a webhook has more than one entrypoint, the operator cannot tell which sender sent an event. The operator also cannot see the headers that carry an event's meaning: in the audit that was X-Shop-Event: order.created, and the same goes for the sender's user agent and any signature header.
An expanded event in the event log shows the entrypoint it arrived at. That is the entrypoint's description, "Entrypoint" when it has none, or "deleted entrypoint". The entrypoint's URL and UUID are never shown here.
It also shows the full request headers, one per line, HTML-escaped, behind the admin login like the body.
The per-event page from #369 shows the same two things, through the same rendering, whichever of the two lands second.
Tests: two events that arrive at two different entrypoints show their own entrypoint and headers.
PRIORITY: from the owner's audit request of 1 October (#377), in the tier of #367 to #376.
Model: opus-5-5
Owner's request, https://git.eeqj.de/sneak/webhooker/issues/377 (chat, 2026-10-01):
> audit the whole app for stupid cases of missing functionality or basic things like this (like the stats panel at the top that i requested).
What is missing: the receiver stores each event's complete request headers and the entrypoint it arrived at (`Event.Headers` and `Event.EntrypointID`), but no page shows either. The event log shows only the method, event ID, content type and body; `eventLogColumns` in `internal/handlers/event_log_view.go` does not even load the other two.
So when a webhook has more than one entrypoint, the operator cannot tell which sender sent an event. The operator also cannot see the headers that carry an event's meaning: in the audit that was `X-Shop-Event: order.created`, and the same goes for the sender's user agent and any signature header.
The query string is a separate gap, https://git.eeqj.de/sneak/webhooker/issues/312.
Definition of done:
- An expanded event in the event log shows the entrypoint it arrived at. That is the entrypoint's description, "Entrypoint" when it has none, or "deleted entrypoint". The entrypoint's URL and UUID are never shown here.
- It also shows the full request headers, one per line, HTML-escaped, behind the admin login like the body.
- The per-event page from https://git.eeqj.de/sneak/webhooker/issues/369 shows the same two things, through the same rendering, whichever of the two lands second.
- Tests: two events that arrive at two different entrypoints show their own entrypoint and headers.
PRIORITY: from the owner's audit request of 1 October (https://git.eeqj.de/sneak/webhooker/issues/377), in the tier of https://git.eeqj.de/sneak/webhooker/issues/367 to https://git.eeqj.de/sneak/webhooker/issues/376.
Model: opus-5-5
clawbot
self-assigned this 2026-10-01 22:06:20 +02:00
An expanded event in the event log, and the event's own page, show the entrypoint it arrived at (its description, "Entrypoint" when it has none, or "deleted entrypoint"; never its URL or UUID) and its full request headers, one per line, sorted by name, escaped by the templates.
Both pages draw the two through one shared template, as the body already is since #369; the event log loads Event.Headers and Event.EntrypointID with its other columns, so no query per event.
Tests: two events arriving at two different entrypoints each show their own entrypoint and headers on both pages; a deleted entrypoint reads "deleted entrypoint"; a header value with < and > comes through escaped.
Model: opus-5-5
Plan.
- An expanded event in the event log, and the event's own page, show the entrypoint it arrived at (its description, "Entrypoint" when it has none, or "deleted entrypoint"; never its URL or UUID) and its full request headers, one per line, sorted by name, escaped by the templates.
- Both pages draw the two through one shared template, as the body already is since https://git.eeqj.de/sneak/webhooker/issues/369; the event log loads `Event.Headers` and `Event.EntrypointID` with its other columns, so no query per event.
- Tests: two events arriving at two different entrypoints each show their own entrypoint and headers on both pages; a deleted entrypoint reads "deleted entrypoint"; a header value with `<` and `>` comes through escaped.
Model: opus-5-5
Built in #489, following the plan. An expanded event in the event log, and the event's own page, now show the entrypoint the event arrived at and its full request headers. Both pages draw them through one shared template. The entrypoint is named by its description, "Entrypoint" when it has none, or "deleted entrypoint", and its URL is never shown. Headers come one per line, sorted by name and escaped.
Judgement call: a resubmitted copy shows its original's entrypoint, because the copy carries the original's entrypoint and arrived at none itself.
Judgement call: on the event page the two sit in a new "Request" card between the details and the body.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/webhooker/pulls/489, following the plan. An expanded event in the event log, and the event's own page, now show the entrypoint the event arrived at and its full request headers. Both pages draw them through one shared template. The entrypoint is named by its description, "Entrypoint" when it has none, or "deleted entrypoint", and its URL is never shown. Headers come one per line, sorted by name and escaped.
- Judgement call: a resubmitted copy shows its original's entrypoint, because the copy carries the original's entrypoint and arrived at none itself.
- Judgement call: on the event page the two sit in a new "Request" card between the details and the body.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Owner's request, #377 (chat, 2026-10-01):
What is missing: the receiver stores each event's complete request headers and the entrypoint it arrived at (
Event.HeadersandEvent.EntrypointID), but no page shows either. The event log shows only the method, event ID, content type and body;eventLogColumnsininternal/handlers/event_log_view.godoes not even load the other two.So when a webhook has more than one entrypoint, the operator cannot tell which sender sent an event. The operator also cannot see the headers that carry an event's meaning: in the audit that was
X-Shop-Event: order.created, and the same goes for the sender's user agent and any signature header.The query string is a separate gap, #312.
Definition of done:
PRIORITY: from the owner's audit request of 1 October (#377), in the tier of #367 to #376.
Model: opus-5-5
Plan.
Event.HeadersandEvent.EntrypointIDwith its other columns, so no query per event.<and>comes through escaped.Model: opus-5-5
Built in #489, following the plan. An expanded event in the event log, and the event's own page, now show the entrypoint the event arrived at and its full request headers. Both pages draw them through one shared template. The entrypoint is named by its description, "Entrypoint" when it has none, or "deleted entrypoint", and its URL is never shown. Headers come one per line, sorted by name and escaped.
Model: opus-5-5