TP49 widerlegt und geschlossen — kein Fix, Doku korrigiert

Christoph hat die Praemisse am 2026-10-06 selbst widerlegt: testus@emsenhuber.com
wird von CF Access abgelehnt. Die E-Mail-Bindung der Policy gilt, login_method
hebelt sie nicht aus. Es gab nie eine offene Tuer.

Der Fehler war ein Fehlschluss, kein Raten: Doku-Semantik zu login_method
("welche Methode wurde benutzt") wurde so gelesen, als ersetze der Include die
danebenstehende email-Zeile. include ist ein OR — die Zeilen sind Alternativen,
nicht Bedingungen. Aus "GitHub ist eine Alternative zur E-Mail" wurde "GitHub
allein genuegt", und das stand als Tatsache in der Akte (Fund 2026-07-10).

Belegt: kein IdP traegt eine Domain-Bindung (github/google/onetimepin alle nur
client_id + redirect_url, live per GET .../identity_providers). Die Einschraenkung
kann also nur aus der Policy kommen — und sie greift nachweislich.

Grenze der Aussage: der GitHub-Pfad selbst wurde nicht gemessen, nur geschlossen.

Korrigiert: teilprojekte.md TP49 (Herkunft des Fehlers mitgenannt), cf-tunnel-
mapping.md Paragraf 10 (Ursprungsfund widerlegt, nicht geloescht), Startauftrag
als "NICHT AUSFUEHREN" markiert. Kein Schreibzugriff auf die Terpenfinder-Policy;
blauebluethen-Projektgrenze gewahrt.

Erhalten bleiben nur die Gotchas: 32-Hex-App-IDs, cloudflare-MCP ist read-only
(Write-Probe no-op-PUT -> 1010), Reusable Policy nur per App-PUT detachbar.

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

docs/cf-tunnel-mapping.md

@@ -303,6 +303,25 @@ Tokens: nur im Container-Env + jederzeit via `GET /accounts/…/cfd_tunnel/<id>/
 
 **🔴 NEUER FUND (wichtiger als vw!) — Wildcard `*.emsenhuber.net` (`16aaec78`) zu offen:** Policy `christoph` hat `include: email:christoph OR login_method:github OR login_method:google`. **`login_method:<idp>` als include matcht JEDEN, der sich via GitHub/Google einloggt** — nicht nur christoph. D.h. **jeder GitHub-/Google-User erreicht nach Login alle internen Dienste** (hass, grafana, portainer, pve, gitea, …). Fix = die zwei `login_method`-Includes raus (nur `email:christoph` + ggf. weitere erlaubte Mails + `non_identity bf4` + `claude-mcp`). **NICHT einseitig geändert** (ändert Login-Verhalten überall) → User-Entscheidung. War im Memory schon als „Policy christoph verschlanken" geflaggt.
 
+> ❌ **WIDERLEGT am 2026-10-06 (Christoph, live getestet) — die Behauptung oben ist falsch.**
+> `testus@emsenhuber.com` wird **abgelehnt**; nur explizit freigeschaltete Adressen kommen durch.
+> **Die E-Mail-Bindung der Policy gilt — `login_method` hebelt sie nicht aus.**
+>
+> **Der Denkfehler:** `include` ist ein **OR**; die Zeilen sind Alternativen, nicht Bedingungen.
+> Aus „GitHub ist eine Alternative zur E-Mail" wurde „GitHub allein genügt" — belegt war das nie.
+> Dazu passt, dass **kein** IdP eine Domain-Bindung trägt (live geprüft:
+> `GET /accounts/{id}/access/identity_providers` — github/google/onetimepin alle nur
+> `client_id` + `redirect_url`); die Einschränkung kann also nur aus der Policy kommen, und sie greift.
+>
+> **Es gab hier keine offene Tür.** Der Eintrag stand vom 2026-07-10 bis 2026-10-06 als
+> „wichtiger Fund" in der Akte, gestützt allein auf einen Lese-Schluss — der Test dauerte zwei
+> Minuten. Details + Gotchas: `docs/teilprojekte.md` → `### TP49` (geschlossen, kein Fix).
+> ⚠️ **Nicht separat gemessen:** der GitHub-Pfad selbst (Google→GitHub ist geschlossen, nicht
+> getestet) — deshalb „ungetestet", nicht „bewiesen sauber".
+>
+> ✅ **Unberührt davon bleibt:** TP41 hat den Wildcard ohnehin auf Access-Groups
+> (`zt-humans`/`zt-home`/`zt-automation`) umgestellt — dort steht heute kein `login_method` mehr.
+
 **⏸️ `hass` 400 / `ha-mcp` — zwei getrennte Layer:**
 - **Access-Layer (remote):** HA-Companion-App kann kein interaktives Access-Login → Fix = iPhone in **WARP** enrollen (`Warp Login App` `6c32fe23` `allow:christoph` existiert → christoph darf enrollen). Client-seitig, braucht User am Gerät. Vom Heim-Netz (bf4-IP) ohnehin ohne Login erreichbar.
 - **Origin-Layer:** `hass.emsenhuber.net` gibt **vom Heim-Netz** (Access passt via bf4-IP) trotzdem **400** (CF `server:cloudflare`, aber Origin-verursacht) = **HA lehnt den Request ab** — HA-`http:`-Config (`use_x_forwarded_for` + `trusted_proxies` inkl. cloudflared-Range, ggf. Host-Allowlist). **Separates HA-Thema, NICHT Tunnel/Access** — offen.