TP41-Follow-up: App-Launcher D1 (3 Bookmark-Kacheln + Styling), Geli pillepalle670 in zt-humans; TP43 (dw-DNS-Uplink) angelegt; IdP-Kurzanleitungen (Google/Meta)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
99
docs/handoff-20260901-tp41-followup.md
Normal file
99
docs/handoff-20260901-tp41-followup.md
Normal file
@@ -0,0 +1,99 @@
|
||||
# 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.
|
||||
@@ -44,6 +44,10 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
|
||||
Domain) und die `.bf.emsenhuber.net`-Aliase (Caddyfile) auf **einen** Namensraum `emsenhuber.net`
|
||||
ziehen; stale `.16/.17`-Rewrites abbauen; Sollzustand in Nautobot. Handoff:
|
||||
[`docs/handoff-20260901-tp42-naming.md`](handoff-20260901-tp42-naming.md).
|
||||
- 🔜 **TP43 dw-Standort-DNS-Uplink (2026-09-01, angelegt):** dem dw-Standort einen eigenen Resolver/
|
||||
DNS-Uplink mit **site-spezifischen Overrides** geben (erster Fall `420.teilzeitladen.xyz` → BF-Caddy
|
||||
über WG), **inkl. Verhalten bei WG-Disconnect** (Override auf BF-interne IP fällt sonst aus). FritzBox
|
||||
standard kann keinen Per-Host-Override. Geli-Sofortlösung = **WARP** (nicht Teil von TP43). Cross-Projekt.
|
||||
- ✅ **TP16.3 ABGESCHLOSSEN (2026-09-01):** Flip **und** Abbau durch. Öffentlich laufen nur noch
|
||||
`bf-public` (12 Connectoren) und `fm` — die drei Alttunnel `bf-mm`/`bf-nas`/`bf-pve` **und** der
|
||||
projektfremde `terpene-db` sind gelöscht, **7 cloudflared-Container** entfernt (inkl.
|
||||
@@ -490,6 +494,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
|
||||
> | TP40 | 🔜 | HA-Recorder-Retention: 41 GB `states` beschneiden (Okay 09-01) | — |
|
||||
> | TP41 | ⏳ | CF-Access-Reparatur: **T4/T3/T2 ✅**; Token-Altlast geklärt; offen nur noch User-Aufgaben (T5 IdP-Callbacks = OTP-Fix, d47435-Revoke, T3-WARP-Client-Verify) | — |
|
||||
> | TP42 | 🔜 | Namens-Vereinheitlichung bf.lan→emsenhuber.net: `.bf.lan`/`.bf.emsenhuber.net` aus allen Geräten raus, in Nautobot festhalten | — |
|
||||
> | TP43 | 🔜 | dw-Standort-DNS-Uplink: eigener Resolver mit site-Overrides (`420.teilzeitladen.xyz`→BF-Caddy/WG), WG-Disconnect bedacht; Geli sofort per WARP | — |
|
||||
> | — | — | **35 archivierte TPs** in `teilprojekte-archiv.md` (inkl. TP39 ✅ 2026-09-01) | — |
|
||||
|
||||
### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt
|
||||
@@ -2944,6 +2949,32 @@ Problem"). **Abh.:** TP37 (Nautobot-Datenmodell) für Punkt 4; sonst nichts Offe
|
||||
**Status:** 🔜 angelegt 2026-09-01, Ausarbeitung eigene Session. Handoff:
|
||||
[`docs/handoff-20260901-tp42-naming.md`](handoff-20260901-tp42-naming.md).
|
||||
|
||||
### TP43 — dw-Standort-DNS-Uplink (site-spezifische Overrides) ▸ 🔜 ANGELEGT 2026-09-01 (User-Okay erteilt)
|
||||
|
||||
**Auslöser (2026-09-01, TP41-Follow-up):** Geli soll `420.teilzeitladen.xyz` am dw-Standort erreichen.
|
||||
Split-Horizon am dw scheitert an der **FritzBox** (`10.95.10.1`): kein Per-Host-A-Override im Standard
|
||||
(nur DNS-Rebind-Ausnahmen ohne IP). Christoph: *„keine Chance im FritzBox-Standard? … lieber ein TP als
|
||||
uns verfranzen. Geli kommt rein, das zählt."*
|
||||
|
||||
**Ziel:** dem dw-Standort einen **eigenen Resolver/DNS-Uplink** geben, der **site-spezifische Overrides**
|
||||
hält (erster Fall `420.teilzeitladen.xyz` → BF-Caddy über WG), als DNS der FritzBox/Clients gesetzt.
|
||||
|
||||
**Kernfrage (explizit):** Verhalten bei **WG-Disconnect.** Ein Override auf eine BF-interne IP
|
||||
(`10.40.20.40`) fällt aus, wenn der Tunnel unten ist. Für einen Login-gegateten Dienst gibt es kein
|
||||
„kein Login **und** funktioniert bei WG-down" — Optionen: (a) Override nur bei WG-up (Failover-Resolver),
|
||||
(b) öffentlicher Pfad (CF, mit Login) als Fallback. Zu entwerfen.
|
||||
|
||||
**Sofortlösung (nicht Teil von TP43):** Geli per **WARP** (Session statt täglichem Login, CGNAT egal,
|
||||
degradiert sauber: WG-up = nahtlos, WG-down = öffentliche URL + Login).
|
||||
|
||||
**BF-seitige Prereqs:** Caddy-vhost `420.teilzeitladen.xyz` → macmini-Worker (`10.40.20.167:8890`) mit
|
||||
Cert (DNS-01, `…4148` hat teilzeitladen.xyz-DNS) · WG-Route dw→`10.40.20.40` · Split-Horizon für
|
||||
`420.teilzeitladen.xyz` (heute liefern auch `.36/.37` public). **Vorher verifizieren:** FritzOS-Version +
|
||||
Dauerläufer am dw. Cross-Projekt (teilzeitladen.xyz). Handoff:
|
||||
[`docs/handoff-20260901-tp41-followup.md`](handoff-20260901-tp41-followup.md).
|
||||
|
||||
**Status:** 🔜 angelegt 2026-09-01, eigene Session.
|
||||
|
||||
### TP37 — Nautobot als durchgehende Netzwerkdoku: Hosts/Container/Dienste, erster Anwendungsfall CF-Connectoren ▸ 🔜 ANGELEGT 2026-08-30 (User-Okay erteilt)
|
||||
> **Christophs Formulierung (2026-08-30):** *„können wir das setup mit den cf-connectoren dann auch in
|
||||
> nautobot abbilden. quasi eine durchgehende netzwerkdoku stück für stück. muss eh fast sein, da du auf
|
||||
|
||||
Reference in New Issue
Block a user