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 wrong: adding or editing an http or slack target whose URL resolves to a private address, such as a box on the operator's own network, fails with "Invalid target URL: target IP 10.1.2.3: blocked private, reserved or cloud metadata address". Nothing tells the operator that this refusal is deliberate, or that the server's ALLOWED_EGRESS_CIDRS setting opens named networks. Only the README says so, and per the README, forwarding to one's own network is what webhooker is mostly for. (validateTargetURL in internal/handlers/source_management.go)
Definition of done:
That refusal adds one sentence: private and reserved addresses are refused by default, and the server's ALLOWED_EGRESS_CIDRS setting allows named networks. It points to the README section "Allowing egress to your own network".
The message never suggests allowing everything.
It is shown on the form once #370 and #381 land, and in the current error response until then.
Test: a private destination's refusal contains the sentence.
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 wrong: adding or editing an `http` or `slack` target whose URL resolves to a private address, such as a box on the operator's own network, fails with "Invalid target URL: target IP 10.1.2.3: blocked private, reserved or cloud metadata address". Nothing tells the operator that this refusal is deliberate, or that the server's `ALLOWED_EGRESS_CIDRS` setting opens named networks. Only the README says so, and per the README, forwarding to one's own network is what webhooker is mostly for. (`validateTargetURL` in `internal/handlers/source_management.go`)
Definition of done:
- That refusal adds one sentence: private and reserved addresses are refused by default, and the server's `ALLOWED_EGRESS_CIDRS` setting allows named networks. It points to the README section "Allowing egress to your own network".
- The message never suggests allowing everything.
- It is shown on the form once https://git.eeqj.de/sneak/webhooker/issues/370 and https://git.eeqj.de/sneak/webhooker/issues/381 land, and in the current error response until then.
- Test: a private destination's refusal contains the sentence.
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:26 +02:00
Plan. The issue body is the brief. The refusal for a private or reserved destination gains one fixed sentence saying these addresses are refused by default and that the server's ALLOWED_EGRESS_CIDRS setting allows named networks, naming the README section "Allowing egress to your own network". It is added where the refusal is built (validateTargetURL), so the same text reaches the form once #370 and #381 show errors there. A test checks it for http and slack targets, on add and on edit.
Model: opus-5-5
Plan. The issue body is the brief. The refusal for a private or reserved destination gains one fixed sentence saying these addresses are refused by default and that the server's `ALLOWED_EGRESS_CIDRS` setting allows named networks, naming the README section "Allowing egress to your own network". It is added where the refusal is built (`validateTargetURL`), so the same text reaches the form once https://git.eeqj.de/sneak/webhooker/issues/370 and https://git.eeqj.de/sneak/webhooker/issues/381 show errors there. A test checks it for `http` and `slack` targets, on add and on edit.
Model: opus-5-5
Built in #407. Refusing an http or slack target at a private or reserved address, on add or edit, now adds: private and reserved addresses are refused by default; the server's ALLOWED_EGRESS_CIDRS setting allows named networks (see "Allowing egress to your own network" in the README). Link-local and cloud metadata refusals, which no setting lifts, do not get it.
Judgement call: Azure's WireServer address (168.63.129.16) shares the private-range refusal, so it gets the sentence too; the README already says listing it reopens it.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/webhooker/pulls/407. Refusing an `http` or `slack` target at a private or reserved address, on add or edit, now adds: private and reserved addresses are refused by default; the server's `ALLOWED_EGRESS_CIDRS` setting allows named networks (see "Allowing egress to your own network" in the README). Link-local and cloud metadata refusals, which no setting lifts, do not get it.
Judgement call: Azure's WireServer address (`168.63.129.16`) shares the private-range refusal, so it gets the sentence too; the README already says listing it reopens it.
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 wrong: adding or editing an
httporslacktarget whose URL resolves to a private address, such as a box on the operator's own network, fails with "Invalid target URL: target IP 10.1.2.3: blocked private, reserved or cloud metadata address". Nothing tells the operator that this refusal is deliberate, or that the server'sALLOWED_EGRESS_CIDRSsetting opens named networks. Only the README says so, and per the README, forwarding to one's own network is what webhooker is mostly for. (validateTargetURLininternal/handlers/source_management.go)Definition of done:
ALLOWED_EGRESS_CIDRSsetting allows named networks. It points to the README section "Allowing egress to your own network".PRIORITY: from the owner's audit request of 1 October (#377), in the tier of #367 to #376.
Model: opus-5-5
Plan. The issue body is the brief. The refusal for a private or reserved destination gains one fixed sentence saying these addresses are refused by default and that the server's
ALLOWED_EGRESS_CIDRSsetting allows named networks, naming the README section "Allowing egress to your own network". It is added where the refusal is built (validateTargetURL), so the same text reaches the form once #370 and #381 show errors there. A test checks it forhttpandslacktargets, on add and on edit.Model: opus-5-5
Built in #407. Refusing an
httporslacktarget at a private or reserved address, on add or edit, now adds: private and reserved addresses are refused by default; the server'sALLOWED_EGRESS_CIDRSsetting allows named networks (see "Allowing egress to your own network" in the README). Link-local and cloud metadata refusals, which no setting lifts, do not get it.Judgement call: Azure's WireServer address (
168.63.129.16) shares the private-range refusal, so it gets the sentence too; the README already says listing it reopens it.Model: opus-5-5