At the end of #2 you asked what other changes, along the lines of live reload, would make the sidecar easier to administer. These are the proposals, for you to pick from. None of them is in the spec update that closes issue 2; each would be its own spec change.
An admin command built into the program. The spec has the admin endpoints used through docker exec, but the container is meant to hold only the program, so there is nothing inside it to call them with. The same program, run through docker exec, would list bans, ban or unban an address, and show why an address was refused, with no token and no separate HTTP client.
Lists in watched files. ALLOW_NETS, RATE_LIMIT_EXEMPT_NETS, DENY_NETS, the country lists and the AS number and country percentages are settings, read once at start, so changing one means restarting the container. Each could also be kept in a plain text file, one entry per line with comments allowed, which the program watches and reads again like the rule files.
Trying rules against saved traffic. The same program, given a saved request log, would print which rules match which past requests, so a new rule can be checked for false hits before it goes into the rules directory.
A pause after an admin lifts a ban. The address is not banned again automatically for a set time, such as a day, so the same traffic does not ban it again before the cause is fixed.
A daily summary. One alert a day to the configured destination with the bans made, the AS numbers and countries refused most, and the rules that matched most.
Recommendation: 1 and 2 next, as one spec change. They remove the remaining reasons to restart the container or to make an HTTP call by hand for routine work. 3 to 5 can wait until the first version has run against real traffic.
Model: opus-5-5
At the end of https://git.eeqj.de/sneak/smallwebwaf/issues/2 you asked what other changes, along the lines of live reload, would make the sidecar easier to administer. These are the proposals, for you to pick from. None of them is in the spec update that closes issue 2; each would be its own spec change.
1. An admin command built into the program. The spec has the admin endpoints used through `docker exec`, but the container is meant to hold only the program, so there is nothing inside it to call them with. The same program, run through `docker exec`, would list bans, ban or unban an address, and show why an address was refused, with no token and no separate HTTP client.
2. Lists in watched files. `ALLOW_NETS`, `RATE_LIMIT_EXEMPT_NETS`, `DENY_NETS`, the country lists and the AS number and country percentages are settings, read once at start, so changing one means restarting the container. Each could also be kept in a plain text file, one entry per line with comments allowed, which the program watches and reads again like the rule files.
3. Trying rules against saved traffic. The same program, given a saved request log, would print which rules match which past requests, so a new rule can be checked for false hits before it goes into the rules directory.
4. A pause after an admin lifts a ban. The address is not banned again automatically for a set time, such as a day, so the same traffic does not ban it again before the cause is fixed.
5. A daily summary. One alert a day to the configured destination with the bans made, the AS numbers and countries refused most, and the rules that matched most.
Recommendation: 1 and 2 next, as one spec change. They remove the remaining reasons to restart the container or to make an HTTP call by hand for routine work. 3 to 5 can wait until the first version has run against real traffic.
Model: opus-5-5
sneak
was assigned by clawbot2026-09-23 14:52:55 +02:00
i don't like any of these. they are all rejected. there should be one and only one listener and any/all admin commands come in through the front door like everything else.
i don't like any of these. they are all rejected. there should be one and only one listener and any/all admin commands come in through the front door like everything else.
Recorded: all five proposals are rejected. The ruling for the spec is one listener only, with every admin command coming in through it like any other request. That rules out a separate admin port and admin tooling run through docker exec.
This changes issue 27 (the admin listener) and the admin sections of PR 9: the admin endpoints move onto the single listener. The smallwebwaf repo-manager carries this into the spec when the spec work resumes. Closing this issue.
Model: opus-5-5
Recorded: all five proposals are rejected. The ruling for the spec is one listener only, with every admin command coming in through it like any other request. That rules out a separate admin port and admin tooling run through `docker exec`.
This changes [issue 27](https://git.eeqj.de/sneak/smallwebwaf/issues/27) (the admin listener) and the admin sections of [PR 9](https://git.eeqj.de/sneak/smallwebwaf/pulls/9): the admin endpoints move onto the single listener. The smallwebwaf repo-manager carries this into the spec when the spec work resumes. Closing this issue.
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.
At the end of #2 you asked what other changes, along the lines of live reload, would make the sidecar easier to administer. These are the proposals, for you to pick from. None of them is in the spec update that closes issue 2; each would be its own spec change.
docker exec, but the container is meant to hold only the program, so there is nothing inside it to call them with. The same program, run throughdocker exec, would list bans, ban or unban an address, and show why an address was refused, with no token and no separate HTTP client.ALLOW_NETS,RATE_LIMIT_EXEMPT_NETS,DENY_NETS, the country lists and the AS number and country percentages are settings, read once at start, so changing one means restarting the container. Each could also be kept in a plain text file, one entry per line with comments allowed, which the program watches and reads again like the rule files.Recommendation: 1 and 2 next, as one spec change. They remove the remaining reasons to restart the container or to make an HTTP call by hand for routine work. 3 to 5 can wait until the first version has run against real traffic.
Model: opus-5-5
i don't like any of these. they are all rejected. there should be one and only one listener and any/all admin commands come in through the front door like everything else.
Recorded: all five proposals are rejected. The ruling for the spec is one listener only, with every admin command coming in through it like any other request. That rules out a separate admin port and admin tooling run through
docker exec.This changes issue 27 (the admin listener) and the admin sections of PR 9: the admin endpoints move onto the single listener. The smallwebwaf repo-manager carries this into the spec when the spec work resumes. Closing this issue.
Model: opus-5-5