mivita/dev/subdomain-optimization-gpt-5-v2/README.md
2025-10-20 17:42:08 +02:00

48 lines
2.3 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Subdomain & Session Handling Optimierungsvorschlag (GPT-5)
Dieses Paket enthält einen sauberen, zweistufigen Ansatz für Domain- und Session-Handling, um Probleme mit doppelt initialisierten Sessions und inkonsistenten `user_shop`-Zuständen zu vermeiden. Es ändert keine bestehenden Dateien. Integration ist in `INTEGRATION.md` beschrieben.
## Ziele
- Frühe Domain-Auflösung ohne Session-Zugriff (vermeidet doppelte Session-Erstellung)
- Späte, robuste Session-/Cookie-Synchronisierung (Sticky-UserShop über Subdomains)
- Kompakte, gut getestete Einheiten (Middleware + Service)
- Abwärtskompatible Session-Keys optional möglich (für schrittweise Migration)
## Architektur (Kurzfassung)
- DomainBootstrap (früh, vor StartSession):
- Parst Host → `DomainContext` (ohne Sessionzugriff)
- Setzt `config('session.domain')` und `config('app.url')` frühzeitig
- Hinterlegt `DomainContext` im Container/Request-Attribute
- DomainSessionSync (spät, nach StartSession):
- Synchronisiert `user_shop` in Session und Cookie (sticky über Subdomains)
- Nutzt `UserShopSessionManager` (Service)
- Hält sich strikt an die „kein Sessionzugriff vor StartSession“-Regel
- UserShopSessionManager:
- Vereinheitlicht Lesen/Schreiben von `user_shop` (Session + Cookie)
- Optional: Legacy-Keys (`session('user_shop')`) für Bestands-Views/Controller setzen
## Dateien
- `src/Http/Middleware/DomainBootstrap.php`
- `src/Http/Middleware/DomainSessionSync.php`
- `src/Services/UserShopSessionManager.php`
- `config/example.subdomain_optimization.php` (Beispielkonfiguration)
- `INTEGRATION.md` (Reihenfolge/Registrierung & Migrationspfad)
- `docs/ADR-001-domain-session-handling.md` (Entscheidungsdokumentation)
## Warum dieser Ansatz?
Die aktuelle Logik greift in Teilen zu früh auf die Session zu, bevor die Kernel-`StartSession`-Middleware aktiv ist. Das kann zu zwei Session-IDs in einem Request führen und verhindert ein konsistentes Sticky-Shop-Verhalten über `in.` und `checkout.`. Der zweistufige Ansatz trennt strikt:
- Domänenauflösung/Kontext (rein, keine Session)
- Zustandssynchronisierung (nur nach Start der Session)
Damit werden doppelte Sessions vermieden und der `user_shop` zuverlässig über Subdomains hinweg getragen.
Weitere Details siehe `INTEGRATION.md` und `docs/ADR-001-domain-session-handling.md`.