bf-infra/docs/handoff-20260901-tp41-followup.md

Handoff 2026-09-01 — TP41 Follow-up: IdP-Feinschliff, App-Launcher, Geli-Zugänge, dw-DNS

Kleine Folgesession nach TP41 (T4/T3/T2 durch). Sammelt die Rest-Punkte rund um Logins für Geli, die App-Launcher-Seite und den dw-Split-Horizon für Terpenfinder. Mehrere Punkte sind User-Konsolen-Aufgaben (Google/Meta), dafür je eine Kurzanleitung.

Status je Punkt (Stand dieser Session)

#	Punkt	Stand
1	GitHub-Login	✅ funktioniert (User bestätigt)
2	Google „Zugriff blockiert: nur innerhalb der Organisation"	✅ gefixt — User hat Consent-Screen auf External gestellt; Google-Login läuft (bestätigt 2026-09-01). Anleitung §A war der Weg.
3	Meta/Facebook einbinden	❌ für TP41 abgesagt (User-Entscheid 2026-09-01) — optional, kein Bedarf. Keine App, kein CF-IdP angelegt. Geli via OTP+Google voll gedeckt. §B nur noch als Anleitung, falls später gewünscht.
4	Geli-Zugänge hinterlegen	✅ pillepalle670@gmail.com in zt-humans. FB-Konto-Mail = angelikahy@outlook.de (schon drin → Facebook automatisch abgedeckt, sobald Meta läuft). Instagram = kein CF-IdP.
5	App-Launcher überarbeiten	✅ D1 umgesetzt — 3 Bookmark-Kacheln (Vaultwarden/Home Assistant/Terpenfinder), Bundle-/Wildcard-/Terpene-self_hosted-Kacheln aus dem Launcher genommen (Policies unverändert geprüft), Launcher gestylt (Titel „BF-Zugänge", Begrüßung, Buttons).
6	420.teilzeitladen.xyz an dw	✅ Entscheidung: Geli sofort per WARP; das dw-Site-DNS-Uplink-Thema → TP43 (angelegt).

---

§A — Google-Login-Fix (User, Google Cloud Console)

Fehler „cloudflare kann nur innerhalb der Organisation verwendet werden" = der OAuth-Consent-Screen des Google-Projekts steht auf User Type = Internal (nur Workspace-Org-Konten). Gelis Gmail ist extern → blockiert. Fix (der CF-Google-IdP c757… bleibt unverändert, nur die Consent-Einstellung ändert sich):

1. https://console.cloud.google.com → richtiges Projekt (das, aus dem die Google-OAuth-Client-ID stammt).
2. APIs & Services → OAuth consent screen (neu: „Google Auth Platform → Audience").
3. User Type / Audience von Internal auf External stellen.
4. Veröffentlichen: Publishing status → „In production" (dann kann jedes Google-Konto rein). Alternativ in „Testing" bleiben und Gelis Gmail als Test user eintragen.
5. Danach Login-Test mit Gelis Google-Konto. (Bei „External/unverified" kommt ggf. ein „unbestätigte App"-Hinweis — für den kleinen Kreis unkritisch, oder App verifizieren lassen.)

§B — Meta/Facebook als Login (User legt App an, dann CF-IdP durch mich)

Es gibt noch keine Facebook-App (Creds leer). Schritte:

1. https://developers.facebook.com → My Apps → Create App → Use case „Authenticate and request data from users with Facebook Login" (Consumer).
2. Produkt Facebook Login hinzufügen.
3. Facebook Login → Settings → Valid OAuth Redirect URIs = https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback
4. App settings → Basic: App ID + App Secret → an mich (in ~/.secrets, nicht in den Chat), ich trage sie in mcp/cloudflare/.env (FACEBOOK_APP_ID/SECRET) ein und lege den CF-Facebook-IdP an.
5. App Mode → Live (sonst dürfen nur App-Rollen/Tester rein); Geli ggf. als Tester eintragen.
6. ⚠️ CF matcht die Policy über die E-Mail, die Facebook zurückgibt — diese E-Mail muss in zt-humans stehen (s. §C).

§C — Geli: Zugangsmethoden (Matrix)

CF Access matcht Personen über die E-Mail der Identität (nicht über Usernamen). Stand:

Methode	Gelis Angabe	CF-Status	To-Do
OTP (E-Mail-Code)	angelikahy@outlook.de	✅ in zt-humans	—
OTP + Google	pillepalle670@gmail.com	✅ heute ergänzt	Google-Fix §A nötig, damit Google-Login geht
Facebook	User 35Lika.Ange	⏳	Facebook-App (§B); dann die E-Mail ihres FB-Kontos in zt-humans — welche ist das? (vermutlich eine der beiden obigen)
Instagram	angelikahy	❌ CF Access hat keinen Instagram-IdP	Nicht möglich als Direkt-Login → Geli nutzt Facebook/Google/OTP

→ Sobald Gelis FB-Konto-E-Mail bekannt ist und sie eine der schon hinterlegten Adressen ist, ist Facebook automatisch abgedeckt. Sonst diese E-Mail zusätzlich in zt-humans aufnehmen.

§D — App-Launcher emsenhuber.cloudflareaccess.com überarbeiten

Ist-Analyse (live): Der Launcher (App 6df5c431, landing_page_design={} = ungestylt) zeigt Kacheln aus den Access-Apps mit app_launcher_visible=true:

• 1dbc45ca „hass, vw, gitea" (self_hosted, Domain vw.emsenhuber.net) → eine Kachel, verlinkt nur vw.
• 16aaec78 *.emsenhuber.net (Wildcard) → Kachel ohne sinnvolles Ziel.
• e6a7991f Terpenfinder v3 (420.teilzeitladen.xyz) → eigene Kachel ✅. Deshalb „stimmt nicht mehr": vw/hass/gitea teilen sich eine Kachel, die Wildcard-Kachel stört.

Ziel: je ein sauberer Button für Vaultwarden, Home Assistant, Terpenfinder + freundlichere Seite. Zwei Wege (Entscheidung offen):

• D1 — CF-nativ (empfohlen, „diese Seite"): je ein Bookmark-App (type bookmark) für vw/hass/ terpenfinder mit Name + Logo (eigene Kachel/Link), die Wildcard-Kachel aus dem Launcher nehmen, landing_page_design setzen (Titel z.B. „BF-Zugänge", Begrüßung, Farbe, Logo). Reversibel, in Minuten. Grenze: CF-Styling = Titel/Text/Farbe/Logo + uniforme Kacheln.
• D2 — Custom-Landing-Page: eigene HTML-Seite (Caddy, hinter Access) mit voller Gestaltung/großen Buttons. Mehr Design, mehr Aufwand (eigener vhost + Access-Regel).

§E — dw: 420.teilzeitladen.xyz lokal auflösen (FritzBox 10.95.10.1)

Ehrliche FritzBox-Antwort: Eine FritzBox kann keinen freien „Hostname → beliebige IP"-Override im GUI (nur DNS-Rebind-Schutz-Ausnahmen = Whitelist gegen Rebind-Blockade, ohne IP-Zuweisung). Ein sauberer Split-Horizon für genau diesen Namen braucht daher einen kleinen lokalen Resolver am dw (dnsmasq/AdGuard/Pi-hole auf einem Dauerläufer): address=/420.teilzeitladen.xyz/<BF-Caddy-über-WG> + Rest weiterleiten; diesen Resolver als DNS der FritzBox bzw. der Clients setzen. ⚠️ Vor Umsetzung verifizieren (nicht aus dem Kopf): FritzOS-Version am dw + ob ein Dauerläufer da ist. BF-seitige Prereqs (fehlen noch):

1. Caddy-vhost 420.teilzeitladen.xyz → macmini-Worker (10.40.20.167:8890) mit Cert (DNS-01, …4148 hat jetzt teilzeitladen.xyz-DNS).
2. WG-Route dw → 10.40.20.40 (Caddy) muss stehen.
3. Split-Horizon für 420.teilzeitladen.xyz (heute liefern auch .36/.37 public für diesen Namen). Cross-Projekt (teilzeitladen.xyz). Alternative aus Ur-Handoff: Gelis Gerät in WARP (Session statt Login, CGNAT unkritisch) + Access-Policy auf die WARP-Identität — spart den ganzen dw-DNS-Umbau.

Entscheidungen (2026-09-01, getroffen)

1. App-Launcher: ✅ D1 (CF-nativ) — umgesetzt (s. §D / Punkt 5).
2. Gelis Facebook-Mail: ✅ angelikahy@outlook.de — schon in zt-humans, Facebook damit abgedeckt.
3. dw-Ansatz: ✅ Geli per WARP (sofort); Site-DNS-Uplink als TP43 ausgelagert.

Verbleibende offene To-Dos (User)

• §A Google-Consent-Screen auf External ✅ erledigt — Google-Login läuft (2026-09-01).
• §B Facebook-App anlegen ❌ abgesagt für TP41 (User-Entscheid 2026-09-01) — optional; §B bleibt als Anleitung stehen, falls später doch gewünscht.
• d47435-Revoke ✅ erledigt · T3-WARP-Client-Verify ✅ ok (User, 2026-09-01).
• Geli in WARP: ✅ CF-seitig nichts zu tun — Enrollment läuft über App „Warp Login App" (6c32fe23…) → bf-users → Gruppe zt-humans, die Gelis Mails schon enthält; sie darf bereits enrollen. Terpenfinder-geli-Policy lässt sie per E-Mail durch. Rest = Handgriff auf Gelis Gerät: WARP installieren, Team emsenhuber, Login OTP angelikahy@outlook.de oder Google pillepalle670@gmail.com. Permission-Frage: CF-seitig keine nötig; /access/seats per MCP nicht nutzbar (10405, Endpoint will User-Token statt Account-Token — kein Scope-Fix, für Enroll irrelevant).
• T5 (TP41) ✅ GitHub- und Google-Login laufen (bestätigt).
• TP43 (dw-Site-DNS) bei Gelegenheit.

TP41-Auth-Kern damit abgeschlossen (2026-09-01): T2/T3/T4/T5 ✅, FB abgesagt, d47435-Revoke ✅, WARP-Verify ✅, Geli CF-seitig fertig. Nichts mehr auf Claude-/CF-Seite offen — verbleibt nur Gelis WARP-Client auf ihrem Gerät.