docs/sso.md: the sign-in setup ipodderx.sdf1.net really runs

Authentik is Cloudflare Access's OpenID Connect identity provider, not
something in the request path, and the tunnel's requests reach ipx from
the content_default gateway, 192.168.16.1, not 127.0.0.1. The page is
rewritten from what was measured, with checks for both the trusted and
the refused path, and docs/history.md records every change made to get
there with how to undo it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TAC7sLVqfKmY6rsTLXzNgk

docs/history.md

@@ -6,6 +6,46 @@ reasoning lives. New write-ups go at the top.
 
 See [README.md](../README.md) for what the thing is.
 
+## 2026-09-12 — Signing in through Authentik, for real
+
+Ray could not get Authentik's sign-in to reach ipx, following `docs/sso.md`, which had been written
+without ever being tried. Looking at the Cloudflare account through its API showed that side was
+already complete. Authentik is Zero Trust's OpenID Connect identity provider; the Access application
+`ipodderx` allows only it and a list of five addresses; the tunnel `rays-unraid` routes
+`ipodderx.sdf1.net` to `192.168.1.130:8099`; DNS is a proxied CNAME to the tunnel. Access's log
+showed `rays@sdf1.net` signing in through it. Nothing on Cloudflare was changed, so no other site
+was touched.
+
+The gaps were all at ipx's end: `trusted_header` was empty, `trusted_proxies` held only loopback,
+and the account was called `rays` while the header carries `rays@sdf1.net`.
+
+Finding the address to trust took the most time. The page said `127.0.0.1`, but `cloudflared` runs in
+its own container and reaches ipx through the host's published port. ipx logs no peer addresses, so
+the address was read from `/proc/net/tcp` inside the ipx container: `192.168.16.1`, the gateway of
+`content_default`, where Docker's masquerade puts traffic crossing from another bridge. A request
+from Tower's own shell arrived as `192.168.1.130` instead, and a throwaway `busybox` on the default
+bridge as `192.168.16.1`: the first was refused with the header, the second believed. LAN machines
+keep their own addresses, since Docker forwards published ports with iptables (the userland proxy
+only handles loopback).
+
+Every change, in order, with how to undo it:
+
+1. **Code**, commit `586d2c0`: `ipx user rename`, deployed. Revert the commit and redeploy to
+   remove it; nothing depends on it once used.
+2. **Account**: `docker exec iPodderX ipx user rename rays rays@sdf1.net`. Same id, so its feeds,
+   read state, password and admin rights stayed. Undo: `docker exec iPodderX ipx user rename
+   rays@sdf1.net rays`. Signing in at `/login` now takes the new name.
+3. **Config**, `/mnt/fast/appdata/ipodderx/config.toml`, `[web]`: `trusted_header` from `""` to
+   `"Cf-Access-Authenticated-User-Email"`, and `"192.168.16.1"` added to `trusted_proxies`. The
+   file as it was is `config.toml.2026-09-12-sso.bak` beside it. Undo: copy the backup back and
+   `docker compose -f /mnt/fast/arcane/projects/content/compose.yaml restart ipodderx`.
+4. **Cloudflare, Authentik, Docker networks and other containers**: unchanged. The `busybox` test
+   container was removed when it exited, and its image afterwards.
+
+What the address trusts is any container on Tower that connects through the host's port, not only
+`cloudflared`. Verifying Cloudflare's signed `Cf-Access-Jwt-Assertion` would remove that, and is
+the upgrade if it matters.
+
 ## 2026-09-12 — Trimming the state database
 
 An audit of the database layer, with a read-only copy of production to check it against. The