Confirm changes automatically from the client that made them

A change made over the network answers with a one-time confirm_token
and closes its connection (HTTP/2: a GOAWAY). The web UI and hc send the
token straight back to /confirm, which accepts it only for the newest
change, from the same user and API token, the same address, and over a
new connection: proof that the client can still reach the API through
the new ruleset (an established connection would get through anyway). A
change that cuts its client off can't be confirmed so, and rolls back by
itself. The setting manual_confirm (hc settings set --auto-confirm off)
and hc --no-confirm leave confirming to a person. Changes through the
local socket still need no confirmation. e2e: 136 checks, among them a
lockout change rolled back without anyone confirming.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/api.md

@@ -51,6 +51,10 @@ Calls that change the configuration answer:
 * `confirm_by`: the change is on probation, and is rolled back at that
   time unless `POST /confirm` comes first. Missing for changes made
   through the socket.
+* `confirm_token`: the client that made the change can confirm it by
+  itself with `POST /confirm {"token"}`, from the same address, as the
+  same user and token, over a new connection (the answer closes this
+  one). Missing when a person must confirm (`manual_confirm`).
 * `?dry_run=1` checks the change, with nftables too, and returns what it
   would do, with `"applied": false, "dry_run": true`, and `diff`: the
   ruleset's unified diff.
@@ -89,7 +93,7 @@ Creating answers 201, other changes 200.
  "builtins": {"loopback": true, "established": true, "drop_invalid": true, "icmpv6": true,
               "ping_internal": true, "dhcpv6_client": true, "antispoof": true, "mss_clamp": false},
  "own_prefixes": ["2001:db8::/48"], "antispoof_v4": ["10.0.0.0/8", "..."], "antispoof_v6": ["fc00::/7", "..."],
- "flowtable_devices": ["wan", "eth1"], "probation_seconds": 120}
+ "flowtable_devices": ["wan", "eth1"], "probation_seconds": 120, "manual_confirm": false}
 ```
 
 Lists replace the old ones. `probation_seconds` 0 is the default (120).
@@ -180,7 +184,7 @@ history, but are audited.
 | | |
 |---|---|
 | `GET /probation` | `{"pending": [history IDs], "takeovers": N, "deadline", "seconds_left"}` |
-| `POST /confirm` | keep them: `{"confirmed": N}`; the ruleset is saved for the boot |
+| `POST /confirm` | keep them: `{"confirmed": N}`; the ruleset is saved for the boot. With `{"token"}`, the client confirming its own change (see `confirm_token`): 409 if a newer change is pending, or over the change's own connection; 403 from another user or address |
 | `POST /rollback` | undo them now |
 
 ### History, import, takeover

docs/cli.md

@@ -28,6 +28,7 @@ command and its flags.
 | | `HOUSECARL_SOCKET` | the local socket's path |
 | `--insecure`, `--ca-cert FILE` | | TLS: skip the check, or trust another CA |
 | `-n, --dry-run` | | check and show a change without making it, with the ruleset's diff |
+| `--no-confirm` | | leave a change on probation instead of confirming it once `hc` reaches Housecarl again |
 | `-C, --changeset ID` | `HOUSECARL_CHANGESET` (checked, see [Changesets](#changesets)) | stage configuration changes in this changeset instead of making them |
 | `-o, --output FORMAT` | | `table` (default), `json`, `yaml` or `id` |
 | `-q, --quiet` | | print only errors (and the IDs of new objects) |
@@ -41,14 +42,14 @@ server error.
 Every change is checked as a whole, then by nftables, before it is put
 in force. A refused change says why, with the problem's code
 ([validation.md](validation.md)). An applied one says its history entry
-and any new warnings. Over the network, it is on probation:
+and any new warnings. Over the network, it is on probation, and `hc`
+confirms it by reaching Housecarl again over a new connection
+([operations.md](operations.md#changes-on-probation)):
 
 ```
 $ hc rule add input --from trusted --service ssh --comment "SSH from home"
 created rule input #31 (from trusted · ssh)
-applied on probation (history 12): confirm with 'hc confirm' within 2m0s, or it is rolled back
-$ hc confirm
-confirmed 1 change; it is kept and loaded at boot
+applied and confirmed (history 12): this client reached Housecarl again over a new connection
 ```
 
 Through the socket the change is kept at once:
@@ -203,7 +204,7 @@ See [nat.md](nat.md).
 | Command | |
 |---|---|
 | `settings show` | |
-| `settings set [--input-policy\|--forward-policy\|--output-policy accept\|drop] [--log-drops on\|off] [--builtin NAME=on\|off]... [--own-prefix P]... [--antispoof-v4 P]... [--antispoof-v6 P]... [--flowtable DEV]... [--probation 2m]` | lists given replace the old ones |
+| `settings set [--input-policy\|--forward-policy\|--output-policy accept\|drop] [--log-drops on\|off] [--builtin NAME=on\|off]... [--own-prefix P]... [--antispoof-v4 P]... [--antispoof-v6 P]... [--flowtable DEV]... [--probation 2m] [--auto-confirm on\|off]` | lists given replace the old ones |
 
 ### probation, history, import
 

docs/design.md

@@ -107,6 +107,19 @@ confirmed within two minutes (Settings; `hc confirm`, the banner in the
 web UI, `POST /confirm`), it is rolled back by itself, and the rollback is
 recorded in the history. A change that cuts you off undoes itself.
 
+* **The client that made a change confirms it by itself** once it
+  reaches the API again: the change's answer carries a one-time token and
+  closes its connection (HTTP/2: a GOAWAY), and the web UI and `hc` send
+  the token straight back. That proves something only on a new
+  connection, since the built-in that accepts established connections
+  would let the old one through whatever the change did. So the token is
+  accepted only from the same user (and API token), the same address, a
+  different connection, and for the newest change. A change that cuts its
+  client off can't be confirmed by it, and rolls back. This proves the
+  API is still reachable, not that SSH or the LAN still work; with the
+  API, you can fix those. Settings → "a person confirms each change"
+  (`hc settings set --auto-confirm off`) goes back to confirming by hand;
+  `hc --no-confirm` leaves one change waiting.
 * Changes made through the local socket (`sudo hc …` on the firewall)
   need no confirmation: whoever makes them is already on the machine. One
   made while others are pending joins them.

docs/operations.md

@@ -28,7 +28,25 @@ edits) applies each edit at once instead. With hc, see
 ## Changes on probation
 
 Changes made over the network roll back unless confirmed
-([design.md](design.md#not-locking-yourself-out)):
+([design.md](design.md#not-locking-yourself-out)). The web UI and `hc`
+confirm their own changes once they reach Housecarl again over a new
+connection, so normally nothing waits:
+
+```
+$ hc rule add input --from admins --service ssh
+created rule input #31
+applied and confirmed (history 12): this client reached Housecarl again over a new connection
+```
+
+A change that cuts the client off can't be confirmed that way:
+
+```
+applied on probation (history 13), but couldn't confirm it: … context deadline exceeded
+It is rolled back within 1m50s unless confirmed ('hc confirm')
+```
+
+By hand (with `--no-confirm`, or with Settings → "a person confirms each
+change"):
 
 ```sh
 hc status              # Probation: 2 changes roll back in 97s unless confirmed