StefanMoCoAt
71aea3f41d
All checks were successful
- **Caddyfile:** Verlagerung des CORS-Handlings in den Reverse Proxy, inkl. Unterstützung für Preflight-Anfragen und Header-Optimierungen. - **UI:** Aktualisierung des Versionsmarkers auf `v2026-04-23.21 - CADDY CORS PROXY FIX`. - **Docs:** Ergänzung der Problem- und Lösungshistorie für Version 21.
82 lines
6.2 KiB
Markdown
82 lines
6.2 KiB
Markdown
# Journal-Eintrag: Plan-B Online-Nenn-Formulare
|
|
|
|
**Datum:** 23. April 2026
|
|
**Agenten:** 🎨 [Frontend Expert], 🖌️ [UI/UX Designer], 👷 [Backend Developer], 🧹 [Curator]
|
|
|
|
## 🎯 Zielsetzung
|
|
Erstellung von zwei hoch-optimierten Web-Formularen für die Turniere in Neumarkt (25. & 26. April 2026) im Rahmen des "Plan-B" (Offline-Meldestelle mit E-Mail-Sync).
|
|
|
|
## 🛠️ Durchgeführte Änderungen
|
|
|
|
### 🎨 Frontend & UI/UX
|
|
- **`OnlineNennungFormular.kt`**: Komplette Neugestaltung des Formulars.
|
|
- Integration der spezifischen Bewerbe für **CSN-C Neumarkt (25.04.)** und **CDN-C Neumarkt (26.04.)**.
|
|
- Implementierung der Validierungslogik für den "Jetzt nennen" Button (Bernstein-Orange).
|
|
- Hinzufügen von Feldern für Reiter-Name, Kontakt (E-Mail/Tel), Pferdename und Anmerkungen.
|
|
- Information Density: Alle Bewerbe direkt auswählbar.
|
|
- **Mobile-First Optimierung**: Responsives Layout mittels `BoxWithConstraints`. Vertikaler Stack für Formularfelder auf Mobile, optimierte Paddings, Schriftgrößen und Touch-Targets.
|
|
- **`WebMainScreen.kt`**: Aktualisierung der Landing-Page mit den realen Turnierdaten für Neumarkt.
|
|
- **Mobile-First Optimierung**: Turnier-Karten passen sich an schmale Bildschirme an (Buttons nebeneinander, Icons für bessere UX).
|
|
|
|
### 👷 Backend & Integration
|
|
- **`NennungRemoteRepository.kt`**: Verknüpfung des neuen Payloads mit dem `mail-service`.
|
|
- **`MailController.kt`**: Validierung der API-Schnittstelle. Der Service ist so konfiguriert, dass er:
|
|
1. Die Nennung in der Datenbank persistiert.
|
|
2. Eine Benachrichtigungs-Mail an die Meldestelle (`online-nennen@mo-code.at`) sendet.
|
|
3. Eine automatische Bestätigung an den Reiter schickt.
|
|
|
|
## 🏁 Ergebnis
|
|
Die "Hallo Du!" Test-UI wurde durch produktive, fachlich korrekte Formulare ersetzt. Sobald ein Reiter auf "Jetzt nennen" klickt, wird der E-Mail-Workflow ausgelöst.
|
|
|
|
**Status:** Bereit für den Live-Einsatz am Wochenende. 🚀
|
|
|
|
### 2026-04-23 09:35 - Version 12: Hard-coded HTTPS & Injektions-Fix
|
|
- **Problem**: 'Mixed Content' Fehler blockierte API-Aufrufe, da die Wasm-App trotz HTTPS-Origin versuchte, 'http://10.0.0.50' (Lokale IP) via HTTP zu kontaktieren.
|
|
- **Lösung**:
|
|
- `PlatformConfig.wasmJs.kt`: Implementierung eines sicheren HTTPS-Fallbacks auf `https://api.mo-code.at` im Code, falls die Docker-Injektion (z.B. durch Browser-Cache) fehlschlägt.
|
|
- `dc-planb.yaml`: Statische Konfiguration der HTTPS-URLs ohne Umgebungsvariablen-Platzhalter, um Fehlkonfigurationen am Host auszuschließen.
|
|
- UI-Marker auf `v2026-04-23.12 - HARD-CODED HTTPS` aktualisiert.
|
|
- Fehlerbehandlung in `OnlineNennungFormular.kt` zeigt nun explizit Netzwerkfehler an, falls diese auftreten.
|
|
|
|
### 2026-04-23 10:15 - Version 13: Radikale HTTPS-Priorisierung
|
|
- **Problem**: Trotz harten Fallbacks im Code versuchte der Browser weiterhin `http://10.0.0.50` (Mixed Content) aufzurufen. Ursache war die Priorisierung von dynamischen Variablen und `window.location.origin` in der `PlatformConfig.wasmJs.kt`.
|
|
- **Lösung**:
|
|
- `PlatformConfig.wasmJs.kt`: Alle Logiken zur Erkennung von URLs wurden temporär deaktiviert. Die Funktionen `resolveMailServiceUrl()` und `resolveApiBaseUrl()` geben nun **zwingend** `https://api.mo-code.at` zurück.
|
|
- Dies umgeht jegliches Caching von `index.html` oder fälschlich injizierte Umgebungsvariablen.
|
|
- UI-Marker auf `v2026-04-23.13 - RADICAL HTTPS PRIORITIZATION` aktualisiert.
|
|
|
|
### 2026-04-23 10:45 - Version 14: CORS Reanimation
|
|
- **Problem**: Trotz HTTPS-Fix blockierte die CORS-Policy im Backend die Anfragen von `https://app.mo-code.at`.
|
|
- **Lösung**:
|
|
- `GlobalSecurityConfig.kt`: CORS explizit wieder aktiviert (`.cors { }`), da Microservices im Plan-B direkt (ohne Gateway) angesprochen werden könnten.
|
|
- `MailController.kt`: `@CrossOrigin` um explizite Header (`allowedHeaders = ["*"]`) und Methoden (`methods = [...]`) erweitert, um Preflight-Checks (OPTIONS) korrekt zu bedienen.
|
|
- UI-Marker auf `v2026-04-23.14 - CORS REANIMATION` aktualisiert.
|
|
|
|
### 2026-04-23 11:45 - Version 17: Security Dependency Fix
|
|
- **Problem**: Trotz Version 16 und dem `scanBasePackages` Fix im `mail-service` bestand der CORS-Fehler weiterhin. Ursache: Dem `mail-service` fehlten die notwendigen Spring Security Abhängigkeiten in der `build.gradle.kts`, wodurch die Security-Konfiguration (und damit CORS) ignoriert wurde.
|
|
- **Lösung**:
|
|
- `build.gradle.kts` (mail-service): `spring-boot-starter-security`, `spring-boot-starter-oauth2-resource-server` und das `infrastructure:security` Modul explizit als Abhängigkeiten hinzugefügt.
|
|
- UI-Marker auf `v2026-04-23.17 - SECURITY DEPENDENCY FIX` aktualisiert.
|
|
|
|
### v2026-04-23.19 - NUCLEAR CORS FIX
|
|
- **Problem**: Trotz Patterns in der Security-Konfiguration fehlte der `Access-Control-Allow-Origin` Header bei Preflight-Anfragen.
|
|
- **Lösung**:
|
|
- Implementierung einer `WebMvcConfigurer` Bean direkt in `MailServiceApplication.kt` für ein zweites, redundantes CORS-Mapping.
|
|
- Lockerung der `allowedOriginPatterns` in `GlobalSecurityConfig.kt` auf `*`.
|
|
- **Status**: Versionsmarker auf v19 aktualisiert.
|
|
|
|
### v2026-04-23.20 - CLOUDFLARE DNS VERIFIED & CORS POLISHING
|
|
- **Analyse**: DNS-Einträge in Cloudflare geprüft (Screenshot). Alle Einträge stehen auf "Nur DNS" (graue Wolke). Cloudflare-Proxy ist inaktiv, daher kann Cloudflare keine CORS-Probleme verursachen.
|
|
- **Lösung**:
|
|
- CORS-Konfiguration in `GlobalSecurityConfig.kt` finalisiert: Whitelist für `https://*.mo-code.at` und `http://localhost:[*]` verfeinert.
|
|
- `allowedMethods` um `HEAD` erweitert und `exposedHeaders` hinzugefügt, um Browser-Warnungen zu eliminieren.
|
|
- **Status**: Versionsmarker auf v2026-04-23.20 aktualisiert.
|
|
|
|
### v2026-04-23.21 - CADDY CORS PROXY FIX
|
|
- **Problem**: Trotz umfangreicher Backend-Konfiguration (v20) meldete der Browser weiterhin fehlende CORS-Header bei Preflight-Anfragen (`No 'Access-Control-Allow-Origin' header`).
|
|
- **Lösung**:
|
|
- CORS-Handshaking wurde direkt in den Caddy-Reverse-Proxy (`Caddyfile` der Web-App) verlagert.
|
|
- OPTIONS-Requests werden nun sofort vom Proxy mit `204 No Content` und den korrekten CORS-Headern beantwortet.
|
|
- Damit wird sichergestellt, dass der Browser die Header erhält, noch bevor die Anfrage das Backend erreicht.
|
|
- **Status**: Versionsmarker auf v2026-04-23.21 aktualisiert.
|