bf-infra/docs/tp49-cf-access-startauftrag.md

Startauftrag — TP49: CF-Access login_method-Include ✅ ERLEDIGT (2026-10-06)

Abgeschlossen. Gitea #76, Prosa in docs/teilprojekte.md → ### TP49.

🔴 Diese Datei nicht mehr als Auftrag lesen — der ist ausgeführt. Sie bleibt als Nachweis stehen: Lage, Vorgehen und die Fehlschläge auf dem Weg dorthin.

Der Auftrag (erledigt)

login_method:github aus dem include der Policy christoph der CF-Access-App 420.teilzeitladen.xyz entfernen — nach Rücksprache, wen der Zugang treffen soll.

Ausgeführt (2026-10-06)

github von include nach require verschoben ⇒ email AND github.

	vorher	jetzt
include	email · github · onetimepin	email · onetimepin
require	—	github

Gesetzt über PUT /accounts/{id}/access/policies/{policy_id}, zurückgelesen über beide Endpunkte (App-Pfad + reusable-Pfad) — identisch. Der success:true der API wurde nicht geglaubt, sondern die Policy neu gelesen.

App-ID e6a7991f-466c-4d1d-bac6-4b30fafccce4 · Policy (reusable) 8e44f5d1-8257-443e-a797-b3de939952ee github-IdP 72c1291b… · onetimepin 9024c7a6…

Sweep über alle Apps (login_method in include/require/exclude): genau zwei Treffer, beide in Terpenfinder v3 — christoph (github+onetimepin) und geli (nur onetimepin, harmlos). Interne Apps/Wildcard: sauber (TP41).

🔴 Gotchas — live bestätigt, alle drei neu am 2026-10-06

1. Reusable Policies ändern geht NICHT über den App-Pfad. PUT …/access/apps/{app}/policies/{pol} → 12130 can not update reusable policies through this endpoint. Korrekt: PUT …/access/policies/{policy_id}. ⚠️ Der ältere Merksatz „Reusable Policy nur per App-PUT detachbar" meint das Detach vom App-policies-Array — nicht das Ändern des Inhalts. Zwei verschiedene Operationen.
2. Der cloudflare-MCP ist strikt read-only. Write-Probe: no-op-PUT (byte-identischer Body) → 1010: undefined. Writes nur via CF_API_TOKEN/curl (cd mcp/cloudflare && set -a; . ./.env; set +a). Token nie ausgeben.
3. Access-App-IDs sind 32 Hex — Kurzform 16aaec78 → 12045 invalid_application_id.

⚠️ Was login_method nicht kann

Die ursprüngliche Absicht war eine Kopplung an den GitHub-Username. Das gibt Access nicht her: login_method prüft die Methode, nicht den Nutzer; einen Username-Selector gibt es nicht. Der einzige GitHub-bezogene Identitäts-Selector ist „Identity provider group" — der braucht SCIM, und am hiesigen GitHub-IdP ist scim_config.enabled = false (GET …/scim/groups → 500 (12158)). Weg zu. ⇒ email AND github ist die vollständige Umsetzung des hier Möglichen, keine Notlösung. Eine echte Org-Kopplung bräuchte SCIM aktiviert — eigener TP.

Aktenhistorie — der Umweg (nicht löschen)

Zwischenzeitlich wurde TP49 als Phantom geschlossen — auf Basis eines Google-Tests plus eines Schlusses auf GitHub. Beides falsch:

1. Lese-Schluss als Befund verkauft. „include ist ein OR" + „Google bindet die Adresse" ⇒ „GitHub bindet auch". Nie gemessen, aber als Tatsache in Akte und Issue geschrieben.
2. Der Gegenbeweis war keiner. Der Google-Test zeigt nur Googles Verhalten. Die IdP-Configs sind konfigurationsgleich — das unterscheidende Feld steht nicht in der Config.

Christoph hat mit einem zweiten GitHub-Account getestet: er kam durch. Damit war der Ursprungsfund bestätigt und der Fix nötig.

Lehre: pro IdP einzeln messen, nicht den ersten Test auf den zweiten übertragen.

Verifikation

• Policy über beide Endpunkte zurückgelesen — require trägt github, include nicht mehr
• Sweep: keine weiteren login_method in include außer den bekannten
• Scope: reusable Policy nur an diese eine App gebunden (kein Kollateral)
• Verhaltensabnahme (2026-10-06, echter Login): fremder GitHub-Account → abgewiesen; eigener Zugang + Geli → funktionieren; alle übrigen Auth-Pfade wie erwartet

Status: abgeschlossen. Gitea #76 closed / status:done. Kein offener Punkt.