Warn when TRUSTED_PROXIES is empty in production (closes #149)

With no trusted proxies configured, every client behind the reverse proxy production requires shares one rate-limit bucket per limit, so five POSTs per minute from anywhere holds the login limit full and denies the admin login until restart. The default is still correct; it was the consequence that was invisible. Startup now warns, and the README no longer claims the login limit is per-IP unconditionally.

README.md

@@ -96,7 +96,7 @@ TTY detection, and security headers are always applied.
 | `RETENTION_SWEEP_INTERVAL` | How often the retention reaper and archive sweeper run (Go duration, must be positive) | `1h` |
 | `SESSION_IDLE_TIMEOUT`  | Idle session timeout (Go duration)  | `24h`    |
 | `RECEIVER_RATE_LIMIT`   | Receiver requests/minute per IP per entrypoint (10x that per IP across the route) | `120` |
-| `TRUSTED_PROXIES`       | CIDRs whose forwarded headers are trusted | `""` (none) |
+| `TRUSTED_PROXIES`       | CIDRs whose forwarded headers are trusted (unset: all clients behind a proxy share one rate-limit bucket) | `""` (none) |
 
 #### Trusted proxies
 
@@ -115,6 +115,23 @@ or draining someone else's. Set it to the address of your reverse
 proxy, and to nothing wider. A set but unparseable value aborts
 startup.
 
+That default is safe against forged headers, but leaving it unset in
+production has a cost you must know about. Production runs behind a
+TLS-terminating reverse proxy, so with `TRUSTED_PROXIES` unset every
+request keys on the proxy's own address and all clients share a single
+bucket per limit. For the login and password-change limits that is a
+denial of service anyone can perform: a steady five POSTs per minute
+from any address on the internet keeps the shared login bucket full,
+and the operator's own login then returns HTTP 429 for as long as the
+trickle continues. There is no second administrative path and no
+bypass. Restarting the service clears the in-memory buckets, but a
+sustained trickle re-locks them immediately.
+
+The remedy is to set `TRUSTED_PROXIES` to your reverse proxy's
+address, which restores per-client buckets. webhooker logs a warning
+at startup when `WEBHOOKER_ENVIRONMENT=prod` and `TRUSTED_PROXIES` is
+empty. See [Rate Limiting](#rate-limiting) for what each limit shares.
+
 `X-Real-IP` and `True-Client-IP` are **never** read, from any peer.
 Reverse proxies append to `X-Forwarded-For` but forward other client
 headers verbatim, so a single-valued header is client-controlled even
@@ -890,16 +907,29 @@ connection's own address, unless the peer is listed in
 `TRUSTED_PROXIES`, in which case the forwarded client address is used
 instead. See [Trusted proxies](#trusted-proxies). Deployed without that
 variable set, a client behind a reverse proxy shares one bucket with
-every other client behind the same proxy, which is the safe direction
-to be wrong in: set `TRUSTED_PROXIES` to the proxy's address to get
-per-client limits back. That shared bucket matters more for the
-aggregate limit than for the per-entrypoint one: with `TRUSTED_PROXIES`
-unset behind the reverse proxy a production deployment is required to
-run behind, every request keys on the proxy, so the aggregate limit
-becomes a service-wide ceiling of 1200 requests per minute across all
-senders and all entrypoints, where the per-entrypoint limit's capacity
-still grows with the number of entrypoints. Any deployment with more
-than a handful of busy entrypoints must set `TRUSTED_PROXIES`.
+every other client behind the same proxy. Set `TRUSTED_PROXIES` to the
+proxy's address to get per-client limits back. What the shared bucket
+costs is not the same for every limiter, and the two cases pull in
+opposite directions:
+
+- For the **receiver** limits it costs throughput, which is the safe
+  direction to be wrong in: sharing can only make a limit bind sooner,
+  never let a sender past it. It matters more for the aggregate limit
+  than for the per-entrypoint one: with `TRUSTED_PROXIES` unset behind
+  the reverse proxy a production deployment is required to run behind,
+  every request keys on the proxy, so the aggregate limit becomes a
+  service-wide ceiling of 1200 requests per minute across all senders
+  and all entrypoints, where the per-entrypoint limit's capacity still
+  grows with the number of entrypoints. Any deployment with more than a
+  handful of busy entrypoints must set `TRUSTED_PROXIES`.
+- For the **login and password-change** limits it costs availability of
+  the only administrative path, which is not safe at all. Five POSTs
+  per minute from any address on the internet keeps the single shared
+  login bucket full, and the operator's own login returns HTTP 429 for
+  as long as that trickle continues. A restart clears the in-memory
+  buckets and a resumed trickle re-locks them. Production deployments
+  must set `TRUSTED_PROXIES`; webhooker warns at startup when it is
+  empty in `prod`.
 
 Finer-grained per-webhook rate limits (configured in the web UI and
 enforced in the webhook handler) can layer on top of this env-level
@@ -1118,8 +1148,11 @@ downstream at form-parse time.
   (custom HTTP transport with SSRF-safe dialer that validates resolved
   IPs before connecting, preventing DNS rebinding attacks)
 - **Login rate limiting** via [go-chi/httprate](https://github.com/go-chi/httprate):
-  per-IP sliding-window rate limiter on the login endpoint (5 POST
-  attempts per minute per IP) to prevent brute-force attacks
+  sliding-window rate limiter on the login endpoint, 5 POST attempts
+  per minute per bucket, to slow brute-force attacks. The bucket is per
+  client IP only when `TRUSTED_PROXIES` names the reverse proxy;
+  unset, every client shares one bucket and the login becomes remotely
+  deniable (see [Rate Limiting](#rate-limiting))
 - Prometheus metrics behind basic auth
 - Static assets embedded in binary (no filesystem access needed at
   runtime)