Abschnitt 6 'Umsetzungsstand 17.06.2026': Fundament (Wallet/Ledger/Tier/Topup),
Launch-Funktionen (Extra-PM/Boost/Nachweis/UI/Gate), Phase-2-vorbereitet
(Pruefzaehler, Pfade C/D/G), offene Punkte. Nachzug zu dd5a937 (Dateiname
mit NFD-Umlaut wurde beim ersten Commit verfehlt).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kompakte Go-Live-Checkliste (Live-.env, Migrationen, einmalige Setups,
Stripe-Webhook, Cache-Warmup, Scheduler/Worker, Post-Deploy-Kontrollen).
WS-6 (Auth/Verifizierung/Google) und WS-7 im Detailplan als erledigt
markiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Das Abo-/Bestandsschutz-Gate (User::hasActiveBooking, BookingRequiredException,
Submit-Modal, API 402/422) war bereits implementiert und getestet. Ergänzt wird
die proaktive Block-UX:
- Kunden-Dashboard zeigt bei scharfem Gate (billing.enforce_booking=true) und
fehlender aktiver Buchung einen Banner "Buchung erforderlich, um zu
veröffentlichen" mit Link zur Buchungsseite. Bestandskunden (grandfathered)
sehen den Hinweis nicht; bei offenem Gate bleibt er unsichtbar.
- Tests: Banner aus (Gate offen) / an (Gate scharf, keine Buchung) /
Ausnahme für grandfathered.
Launch-Flip bleibt env-gesteuert (BILLING_ENFORCE_BOOKING), Dev-Default false –
.env.example und Detailplan (WS-5 ✅) dokumentieren den Schalter.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
E/F/Melden/Queue erledigt (95007da); B über WS-2-Firmen-Scope abgedeckt;
A (Tippfehler an veröffentlichten PMs) bewusst nach Phase 2/Pfad C zurückgestellt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Launch-pflichtiger Compliance-Slice: öffentliche Anfrage zu einer PM speist eine
manuelle Admin-Queue (keine KI).
- Migration legal_requests + Model + Enums (Type: dsgvo/personal_rights/report,
Status: open/in_progress/resolved/rejected) + Factory.
- Öffentliches Formular /release/{slug}/rechtliches (LegalRequestController +
web/legal-request.blade.php): typ-abhängiger Hinweistext (Alpine), E-Mail bei
DSGVO/Persönlichkeitsrecht erforderlich, zwei versteckte Honeypot-Felder,
Rate-Limit + Bremse "1 offene Anfrage pro PM/Typ". Regeltexte als Entwurf mit
TODO für rechtliche Finalisierung markiert.
- Routen bewusst in eigener routes/legal.php (entkoppelt vom laufenden Web-Umbau),
host-agnostisch via domains.php eingebunden.
- Admin-Bereich "Recht & Compliance": Sidebar-Nav mit Offen-Zähler, Volt-Queue
index/show (in Bearbeitung/erledigt/abgelehnt/wieder öffnen + interne Notiz).
- Tests: je Typ, Honeypots (Dataset), Bremse, Admin-Queue + Status-Übergänge.
- Doku: Detailplan WS-3-Status + Deployment-Migrationsreihenfolge ergänzt.
Hinweis: Der "Melden"-/E&F-Button auf der PM-Detailseite (release-detail.blade.php)
wird mit dem separaten Web-Frontend-Commit verdrahtet; Ziel ist legal-request.create.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Live-Portal-Domain ist pressekonto.com (nicht .de) – Callback-URL in
.env.example und Deployment-Doku entsprechend gesetzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- .env.example: GOOGLE_REDIRECT_URI explizit auf die Portal-Callback-URL statt
${APP_URL}; Hinweis, dass Google keine .test-Domains akzeptiert.
- Deployment-Doku (§6c): exakte Prod-Callback-URL (pressekonto.de, nicht .com),
lokaler Round-Trip via localhost/https-Tunnel, sonst über gemockte Tests.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Magic-Link und Pressekontakt-Zugang zu einer Seite (/anmeldelink) zusammengeführt;
altes Login-Modal entfernt, /pressekontakt-zugang leitet weiter.
- ContactAccessService deckt jetzt Firmen-E-Mail UND Pressekontakt-E-Mail ab,
portalübergreifend (ohne PortalScope). Eine E-Mail mehrfach hinterlegt → genau
ein Account, dem alle Firmen + Kontakte zugeordnet werden.
- Zugeordnete Firmen erhalten Pivot-Rolle 'responsible' (Schreibzugriff auf
Stammdaten, Kontakte, Pressemitteilungen) statt nur 'member'; bestehende
Lese-Pivots werden hochgestuft, Owner bleiben unangetastet.
- Neuer Login-Listener (SyncCompanyMembershipsOnLogin) frischt die Zuordnungen
bei JEDEM Login (Magic-Link, Passwort, Google) auf – auch nachträglich (API)
hinzugekommene Firmen/Kontakte mit gleicher E-Mail greifen.
- Auth-Bereich erzwingt Hellmodus: aus dem Portal übernommene .dark-Klasse wird
am <html> entfernt (Login war im Dark Mode hängengeblieben).
- Tests: Firmen-E-Mail-Login, Multi-Firmen-Aggregation, Schreibzugriff/Upgrade,
Per-Login-Re-Sync, Auth-Hellmodus. Sicherheits-Doku aktualisiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
RoleAwareLoginResponse gab bei wantsJson() sofort 204 zurück – VOR den
Sicherheitschecks. Ein XHR/JSON-Login eines verifiziert-inaktiven Accounts
erhielt damit eine Session ohne Logout. Checks laufen jetzt zuerst:
verifiziert-inaktiv → Logout + Session-Invalidate + 403 (JSON) bzw. Login mit
Fehler (HTML); unverifiziert → 204 (JSON) bzw. Notice (HTML); danach der
Erfolgsfall.
Tests: JSON-Login eines inaktiven Accounts (403, guest), JSON-Login eines
aktiven Users (204, authentifiziert).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Befund (Review 16.06.): Der Volt-Login machte direkt Auth::attempt() und umging
Fortifys 2FA-Pipeline (2FA-Bypass); zusätzlich existierte der Fortify-POST /login
parallel mit schwächeren Post-Login-Regeln.
Fix (Volt-nativ):
- Volt-Login prüft Credentials ohne sofortiges Login; bei aktivem 2FA wird der
Session-Vertrag login.id/login.remember gesetzt und auf eine neue Volt-
2FA-Challenge-Seite (/two-factor-challenge) geleitet, die an Fortifys
bestehenden Controller postet (TOTP + Recovery-Code).
- Gemeinsame Post-Login-Logik in App\Support\LoginRedirect (rollengerechtes
Home + 403-sicherer intended-Redirect), genutzt von Volt-Login UND Response.
- RoleAwareLoginResponse implementiert jetzt LoginResponse UND
TwoFactorLoginResponse und erzwingt einheitlich: unverifiziert → Notice,
verifiziert-inaktiv → Logout+Fehler, sonst 403-sicherer Redirect. Damit ist
auch der direkte Fortify-POST-Pfad gehärtet.
Tests: 2FA-Übergabe, Challenge-Guard, voller TOTP-Flow, Fortify-POST blockt
inaktive User und hält Customer aus dem Admin-Bereich.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Magic-Link-Versand im Login rate-limited (E-Mail+IP 3/h und IP-only 15/h);
verhindert Mail-Fluten und das Entwerten aktiver Links.
- Inaktive (aber verifizierte) User werden beim Passwort-Login zentral
blockiert (Auth::logout + Fehler) – sichert nur-auth/verified-Routen ab.
- Rollensicherer Login-Redirect: gemerkte intended-Admin-URLs schicken einen
Customer nicht mehr in den 403, sondern auf das rollengerechte Ziel.
- ContactAccess prüft is_active vor jeder Mutation: deaktivierte Bestands-
Accounts werden durch eine Anfrage weder verändert noch angemailt.
- Magic-Link-Verbrauch atomar (UPDATE … whereNull(consumed_at)) – Single-Use
auch bei parallelen Requests.
- Sicherheits-Doku um diese Härtungen + Captcha-Empfehlung ergänzt.
Tests: Rate-Limit, intended-Admin-URL für Customer, inaktiver Login,
ContactAccess ohne Mutation inaktiver Accounts.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Dokumentiert die deployment-kritischen und sicherheitsrelevanten Punkte der
Auth-Phase: Reihenfolge der Migrationen (Verifizierungs-Backfill gegen Lockout,
Legacy-editor→customer-Downgrade), der Sicherheits-Fix der Editor-Über-
berechtigung (65.950 Legacy-User hatten Admin-Zugriff), die Firmen-Scope-
Verhaltensänderung bei PMs und der Magic-Link-Kontaktzugang. PROGRESS-Log-
Eintrag (16.06.) und README-Index ergänzt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bündelt die Launch-Anteile der beiden Decision-Updates (Phase-2/Magic-Link,
Duplicate-Content) mit den Merkliste-Notizen zu einem Plan (WS-1 bis WS-8) inkl.
empfohlener Reihenfolge und Anti-Zombie-Check. Verbindliche Entscheidungen
(15.06.): Legacy-Posten bleiben ungemappt, Pflicht-E-Mail-Verifizierung bei
Registrierung (Ausnahme Magic-Link/Google), Laravel Socialite freigegeben.
README-Index um den Plan ergänzt; Merkliste (Wochenend-Notizen) als Quelle
mit aufgenommen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
