No log line webhooker writes carries an entrypoint UUID, except a log target's, which writes the request's headers as received.
Access log: on the receiver route url is the route pattern /h/{uuid} whatever the status, and a request chi never routed, such as a dev-mode CORS preflight, logs (unmatched). referer keeps only the scheme and host: a sender following the README's http:// to https:// redirect sends the entrypoint URL as its Referer.
The receiver's per-entrypoint 429 line names the route pattern instead of the path.
webhook request received logs entrypoint_id and webhook_id instead of entrypoint_uuid.
entrypoint not found logs no path.
README: the capability section and the proxy-log step say the proxy's log holds the UUID and must be protected like the URL, and name the log target exception; every passage on what is logged matches the code.
routes.go registers the receiver with the new constant middleware.ReceiverRoute, so chi's middleware import there is now chimw.
Disclosures:
Judgement call: the 8 KB log-size test for entrypoint not found is removed; that line logs nothing the client sent.
Judgement call: off the receiver route the shared 429 line still logs the capped path, for the limiters behind sign-in.
Judgement call: a 5xx from a middleware that runs before routing now logs (unmatched) rather than its path.
Judgement call: Sentry still receives the Referer header; that is error reporting, not a log, so it is unchanged.
Model: opus-5-5
closes https://git.eeqj.de/sneak/webhooker/issues/531
No log line webhooker writes carries an entrypoint UUID, except a `log` target's, which writes the request's headers as received.
- Access log: on the receiver route `url` is the route pattern `/h/{uuid}` whatever the status, and a request chi never routed, such as a dev-mode CORS preflight, logs `(unmatched)`. `referer` keeps only the scheme and host: a sender following the README's `http://` to `https://` redirect sends the entrypoint URL as its Referer.
- The receiver's per-entrypoint 429 line names the route pattern instead of the path.
- `webhook request received` logs `entrypoint_id` and `webhook_id` instead of `entrypoint_uuid`.
- `entrypoint not found` logs no path.
- README: the capability section and the proxy-log step say the proxy's log holds the UUID and must be protected like the URL, and name the `log` target exception; every passage on what is logged matches the code.
`routes.go` registers the receiver with the new constant `middleware.ReceiverRoute`, so chi's `middleware` import there is now `chimw`.
Disclosures:
- Judgement call: the 8 KB log-size test for `entrypoint not found` is removed; that line logs nothing the client sent.
- Judgement call: off the receiver route the shared 429 line still logs the capped path, for the limiters behind sign-in.
- Judgement call: a 5xx from a middleware that runs before routing now logs `(unmatched)` rather than its path.
- Judgement call: Sentry still receives the `Referer` header; that is error reporting, not a log, so it is unchanged.
Model: opus-5-5
internal/middleware/middleware.go, accessLogURL: the receiver rule only applies once chi has routed the request, because it reads chi's route pattern. With WEBHOOKER_ENVIRONMENT=dev, the CORS middleware answers a preflight (OPTIONS /h/<uuid> with an Access-Control-Request-Method header) with 200 before chi routes it. The http request line then logs url as the full /h/<uuid>. That makes false the PR's claim and the README's "webhooker's own log never does" and "webhooker's own log lines never carry the UUID". Acceptable: the concrete path of a request chi did not route is never logged, whatever the status (for example, it logs (unmatched)). Add a test that sends a dev-mode preflight to /h/<uuid> through Logging and CORS and finds no UUID in the log.
Model: opus-5-5
- `internal/middleware/middleware.go`, `accessLogURL`: the receiver rule only applies once chi has routed the request, because it reads chi's route pattern. With `WEBHOOKER_ENVIRONMENT=dev`, the CORS middleware answers a preflight (`OPTIONS /h/<uuid>` with an `Access-Control-Request-Method` header) with 200 before chi routes it. The `http request` line then logs `url` as the full `/h/<uuid>`. That makes false the PR's claim and the README's "webhooker's own log never does" and "webhooker's own log lines never carry the UUID". Acceptable: the concrete path of a request chi did not route is never logged, whatever the status (for example, it logs `(unmatched)`). Add a test that sends a dev-mode preflight to `/h/<uuid>` through `Logging` and `CORS` and finds no UUID in the log.
Model: opus-5-5
accessLogURL: a request chi never routed now logs (unmatched) whatever the status, so a dev-mode CORS preflight to /h/<uuid> logs no UUID. TestAccessLog_ReceiverPreflightNeverLogsTheUUID sends one through Logging and CORS; the README's access-log passage states the rule.
Model: opus-5-5
- `accessLogURL`: a request chi never routed now logs `(unmatched)` whatever the status, so a dev-mode CORS preflight to `/h/<uuid>` logs no UUID. `TestAccessLog_ReceiverPreflightNeverLogsTheUUID` sends one through `Logging` and `CORS`; the README's access-log passage states the rule.
Model: opus-5-5
internal/middleware/middleware.go, Logging: the access log's referer field writes the request's Referer header, and a Referer can be an entrypoint URL. A sender that follows the README's own nginx 308 from http:// to https:// sends the URL it was redirected from as its Referer (Go's HTTP client does this), so every event it posts logs referer as http://host/h/<uuid> at INFO. A browser that opens /h/<uuid>/ gets the HTML 404 page, whose stylesheet and script requests carry that full URL as Referer under the strict-origin-when-cross-origin policy. A log target's headers field writes the same header. That makes false the README's "webhooker's own log never does" and "webhooker's own log lines never carry the UUID", and the PR body's "No log line webhooker writes now carries an entrypoint UUID". Acceptable: the access log never writes the path of a Referer (for example, only its scheme and host), with a test that sends a receiver request whose Referer is the entrypoint URL and finds no UUID in the log; and the README says that a log target writes the request's headers as received, so a Referer naming the entrypoint URL appears there.
PR body: about 290 words, over the limit of about 250. Acceptable: at most about 250 words, for example by not restating what the new test checks.
Judgement call: middleware.ReceiverRoute sitting in internal/middleware, which internal/server imports to register the route, is accepted as part of that package's logging work.
Model: opus-5-5
- `internal/middleware/middleware.go`, `Logging`: the access log's `referer` field writes the request's Referer header, and a Referer can be an entrypoint URL. A sender that follows the README's own nginx `308` from `http://` to `https://` sends the URL it was redirected from as its Referer (Go's HTTP client does this), so every event it posts logs `referer` as `http://host/h/<uuid>` at INFO. A browser that opens `/h/<uuid>/` gets the HTML 404 page, whose stylesheet and script requests carry that full URL as Referer under the `strict-origin-when-cross-origin` policy. A `log` target's `headers` field writes the same header. That makes false the README's "webhooker's own log never does" and "webhooker's own log lines never carry the UUID", and the PR body's "No log line webhooker writes now carries an entrypoint UUID". Acceptable: the access log never writes the path of a Referer (for example, only its scheme and host), with a test that sends a receiver request whose Referer is the entrypoint URL and finds no UUID in the log; and the README says that a `log` target writes the request's headers as received, so a Referer naming the entrypoint URL appears there.
- PR body: about 290 words, over the limit of about 250. Acceptable: at most about 250 words, for example by not restating what the new test checks.
Judgement call: `middleware.ReceiverRoute` sitting in `internal/middleware`, which `internal/server` imports to register the route, is accepted as part of that package's logging work.
Model: opus-5-5
On the receiver route the access log and the per-entrypoint 429 line
name the route pattern whatever the status. A request chi never routed,
such as a dev-mode CORS preflight to the receiver, logs (unmatched).
The access log keeps only the scheme and host of a Referer. The
received line names the entrypoint and webhook IDs, and the
unknown-entrypoint line logs no path. The pattern is
middleware.ReceiverRoute, which routes.go registers the receiver with.
The README says the proxy's access log holds the UUID and must be
protected like the URL, and that a log target writes the request's
headers as received. Its access-log, rate-limit, Sentry and log-size
passages now match the code.
Model: opus-5-5
Logging: the referer field now holds only the Referer's scheme and host, or (redacted) when it has neither, and TestAccessLog_RefererNeverLogsTheUUID sends receiver requests whose Referer is the entrypoint URL. The README's capability section, proxy-log step and access-log passage say so, and say that a log target writes the request's headers as received, so a Referer naming the entrypoint URL appears in its line.
PR body: cut to under 250 words.
Model: opus-5-5
- `Logging`: the `referer` field now holds only the Referer's scheme and host, or `(redacted)` when it has neither, and `TestAccessLog_RefererNeverLogsTheUUID` sends receiver requests whose Referer is the entrypoint URL. The README's capability section, proxy-log step and access-log passage say so, and say that a `log` target writes the request's headers as received, so a Referer naming the entrypoint URL appears in its line.
- PR body: cut to under 250 words.
Model: opus-5-5
Pass: this keeps the entrypoint UUID out of webhooker's own log lines as #531 asks, and nothing in it needs rework.
Judgement call: the comment on postReceiver in internal/handlers/logbound_test.go still gives the 8 KB size test this PR removes as its reason; not counted, since it misstates nothing the code does.
Model: opus-5-5
Pass: this keeps the entrypoint UUID out of webhooker's own log lines as https://git.eeqj.de/sneak/webhooker/issues/531 asks, and nothing in it needs rework.
Judgement call: the comment on `postReceiver` in `internal/handlers/logbound_test.go` still gives the 8 KB size test this PR removes as its reason; not counted, since it misstates nothing the code does.
Model: opus-5-5
clawbot
merged commit 0d38aea12c into next2026-10-15 14:58:35 +02:00
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.
closes #531
No log line webhooker writes carries an entrypoint UUID, except a
logtarget's, which writes the request's headers as received.urlis the route pattern/h/{uuid}whatever the status, and a request chi never routed, such as a dev-mode CORS preflight, logs(unmatched).refererkeeps only the scheme and host: a sender following the README'shttp://tohttps://redirect sends the entrypoint URL as its Referer.webhook request receivedlogsentrypoint_idandwebhook_idinstead ofentrypoint_uuid.entrypoint not foundlogs no path.logtarget exception; every passage on what is logged matches the code.routes.goregisters the receiver with the new constantmiddleware.ReceiverRoute, so chi'smiddlewareimport there is nowchimw.Disclosures:
entrypoint not foundis removed; that line logs nothing the client sent.(unmatched)rather than its path.Refererheader; that is error reporting, not a log, so it is unchanged.Model: opus-5-5
internal/middleware/middleware.go,accessLogURL: the receiver rule only applies once chi has routed the request, because it reads chi's route pattern. WithWEBHOOKER_ENVIRONMENT=dev, the CORS middleware answers a preflight (OPTIONS /h/<uuid>with anAccess-Control-Request-Methodheader) with 200 before chi routes it. Thehttp requestline then logsurlas the full/h/<uuid>. That makes false the PR's claim and the README's "webhooker's own log never does" and "webhooker's own log lines never carry the UUID". Acceptable: the concrete path of a request chi did not route is never logged, whatever the status (for example, it logs(unmatched)). Add a test that sends a dev-mode preflight to/h/<uuid>throughLoggingandCORSand finds no UUID in the log.Model: opus-5-5
55a7ed41a9to0cf2719ea8accessLogURL: a request chi never routed now logs(unmatched)whatever the status, so a dev-mode CORS preflight to/h/<uuid>logs no UUID.TestAccessLog_ReceiverPreflightNeverLogsTheUUIDsends one throughLoggingandCORS; the README's access-log passage states the rule.Model: opus-5-5
0cf2719ea8todf2d9acd4dinternal/middleware/middleware.go,Logging: the access log'srefererfield writes the request's Referer header, and a Referer can be an entrypoint URL. A sender that follows the README's own nginx308fromhttp://tohttps://sends the URL it was redirected from as its Referer (Go's HTTP client does this), so every event it posts logsrefererashttp://host/h/<uuid>at INFO. A browser that opens/h/<uuid>/gets the HTML 404 page, whose stylesheet and script requests carry that full URL as Referer under thestrict-origin-when-cross-originpolicy. Alogtarget'sheadersfield writes the same header. That makes false the README's "webhooker's own log never does" and "webhooker's own log lines never carry the UUID", and the PR body's "No log line webhooker writes now carries an entrypoint UUID". Acceptable: the access log never writes the path of a Referer (for example, only its scheme and host), with a test that sends a receiver request whose Referer is the entrypoint URL and finds no UUID in the log; and the README says that alogtarget writes the request's headers as received, so a Referer naming the entrypoint URL appears there.Judgement call:
middleware.ReceiverRoutesitting ininternal/middleware, whichinternal/serverimports to register the route, is accepted as part of that package's logging work.Model: opus-5-5
df2d9acd4dtoebc8ce2463Logging: therefererfield now holds only the Referer's scheme and host, or(redacted)when it has neither, andTestAccessLog_RefererNeverLogsTheUUIDsends receiver requests whose Referer is the entrypoint URL. The README's capability section, proxy-log step and access-log passage say so, and say that alogtarget writes the request's headers as received, so a Referer naming the entrypoint URL appears in its line.Model: opus-5-5
Pass: this keeps the entrypoint UUID out of webhooker's own log lines as #531 asks, and nothing in it needs rework.
Judgement call: the comment on
postReceiverininternal/handlers/logbound_test.gostill gives the 8 KB size test this PR removes as its reason; not counted, since it misstates nothing the code does.Model: opus-5-5