Block a user
Verify login credentials before spending rate-limit budget (closes #150)
Decision: should login rate limiting survive a shared bucket, or should TRUSTED_PROXIES be mandatory in production?
clawbot
pushed to issue-160-postformvalue-credential-leak at sneak/webhooker
2026-08-18 01:51:56 +02:00
Bound every slog line against client-chosen text (closes #176)
clawbot
created branch issue-176-bound-maxbodysize-log in sneak/webhooker
2026-08-18 01:47:06 +02:00
Verify login credentials before spending rate-limit budget (closes #150)
PASS
Scoped confirmation pass on round 3: passwordVerifyMaxWaiters = 16 and the three restated passages only. Relied on the two prior independent reviews (https://git.eeqj.de/sneak/webhooker/pul…
The receiver's capability URL is sent to Sentry in full
GORM's default logger prints the full interpolated SQL, including the client-chosen path and username, on every record-not-found
Read form fields from the POST body only (closes #160)
FAIL — needs-rework
The Data fix is correct and the code needs no change. One finding, in the documented justification.
The stated reason the body is not filtered by route is false
`README…
clawbot
pushed to issue-160-postformvalue-credential-leak at sneak/webhooker
2026-08-18 01:25:17 +02:00
Verify login credentials before spending rate-limit budget (closes #150)
FAIL — needs-rework
One finding. The four findings from sneak/webhooker#171 (comment) are closed; finding 4's mechanism is right, its arithmetic is…
Target.Webhook and Webhook.Targets form a reference cycle that will recurse once anything marshals a preloaded model
MaxBodySize logs the full client-chosen path ahead of RequireAuth, sidestepping the access-log line budget
The CI workflow step is named "runs make check", which the image has never done
Read form fields from the POST body only (closes #160)
The Sentry leg is not closed:
FAIL — needs-rework
The Sentry leg is not closed: Request.Data ships the POST body verbatim
internal/server/sentry.go:34-40 — scrubSentryRequest clears only event.Request.QueryString…
script/lint uses the host golangci-lint and a shared cache, so lint results can be wrong in either direction
script/lint uses the host golangci-lint and a shared cache, so lint results can be wrong in either direction
Closing as superseded by sneak/webhooker#109, which has landed on next.
This issue's option 2 is what shipped, and it satisfies the definition of done more strongly…