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"	🔴 User-Fix — OAuth-Consent-Screen steht auf Internal. Anleitung §A
3	Meta/Facebook einbinden	⏳ App fehlt — FACEBOOK_APP_ID/SECRET in beiden .env leer. Erst App anlegen (Anleitung §B), dann füge ich den CF-IdP hinzu
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 + veröffentlichen (der eigentliche Grund, warum Gelis Google-Login noch scheitert).
• §B Facebook-App anlegen → App ID/Secret an mich (in ~/.secrets) → ich lege den CF-IdP an.
• Geli in WARP aufnehmen (dw-Zugang zu Terpenfinder ohne täglichen Login).
• T5 (TP41) GitHub-Callback ✅; Google-Callback = derselbe Consent-Fix §A.
• TP43 (dw-Site-DNS) bei Gelegenheit.