Frontend: novaris-policy-web-modern-spa (Migrationsphase M7)

Loest den seit M0 in 02-component-mapping.md als spaeteres Ziel benannten, aber nie gebauten Punkt ein: ein eigenstaendiges Frontend fuer novaris-policy-core-modern, Ersatz fuer das server-seitig gerenderte novaris-policy-web-legacy-jsf.

Warum ein separates SPA-Modul statt server-seitigem Rendering

Das Legacy-Original ist ein JSF-Portal - server-seitig gerendert, im selben Deployment-Artefakt wie die Fachlogik. Ein Spring-MVC-Thymeleaf-Aequivalent waere die naheliegende 1:1-Fortfuehrung gewesen, widerspraeche aber der bereits in M4 getroffenen Design-Entscheidung, PolicyController/PolicyApplicationController als reine JSON-REST-API zu bauen (siehe SecurityConfig-Javadoc: "reine JSON-REST-API ohne eigenes Frontend" war zu dem Zeitpunkt noch zutreffend). Ein eigenstaendiges SPA nutzt genau diese bereits vorhandene REST-API, ohne sie nachtraeglich um serverseitiges Rendering zu erweitern - konsequent zu Ende gedacht bedeutet das: Backend bleibt reine API, Frontend ist ein eigenstaendiges, unabhaengig deploybares Artefakt (passt zum Microservice-Charakter der uebrigen modernen Module).

Warum React + Vite + oidc-client-ts

• Vite: schnellster, am wenigsten konfigurationslastiger Weg zu einem TypeScript-React- Projekt - kein eigener Build-Tooling-Lernaufwand fuer dieses Lernprojekt noetig.
• oidc-client-ts: der De-facto-Standard fuer OIDC im Browser (aktiv gepflegt, spec-konforme PKCE-Implementierung) statt einer selbstgebauten Token-Handhabung - Krypto- /Security-relevanter Code sollte nicht neu erfunden werden.
• Kein globaler State-Manager (Redux/Zustand) und keine Server-State-Bibliothek (React Query) - fuer den Funktionsumfang (vier Seiten, direktes fetch pro Seite) waere das vorzeitige Abstraktion gewesen.

Was gebaut wurde

• src/auth/: oidcConfig.ts (Authorization-Code-Flow + PKCE, sessionStorage statt localStorage fuer ein kleineres XSS-Zeitfenster), AuthContext.tsx (React-Context um oidc-client-tss UserManager), roles.ts (UI-seitige Rollenpruefung, spiegelt die @PreAuthorize-Ausdruecke in PolicyManagementService - dient nur der Anzeige, die eigentliche Durchsetzung bleibt serverseitig).
• src/api/policyApi.ts: schmaler fetch-Wrapper, haengt das Bearer-Token an, wirft ApiError mit HTTP-Status fuer die UI-Fehlerbehandlung.
• src/pages/: LoginPage, CallbackPage (OIDC-Redirect-Ziel), PolicyListPage (Kundennummer-Suche), CreatePolicyPage (Antragsformular), PolicyDetailPage (Aktivierung/Stornierung, rollenabhaengig ein-/ausgeblendet).
• Backend-Ergaenzung, ohne die die SPA nicht funktionieren wuerde: SecurityConfig.corsConfigurationSource() - erlaubt gezielt http://localhost:5173 (Vite-Dev-Server), kein Wildcard-Origin.
• keycloak/novaris-realm.json: Client novaris-policy-core um standardFlowEnabled, eine konkrete redirectUris/webOrigins-Angabe (statt des bisherigen, nur fuer Password-Grant-Tests ausreichenden "*") und pkce.code.challenge.method: S256 ergaenzt.

Wie real verifiziert

Kein Browser-Automatisierungswerkzeug (Playwright/Selenium) in dieser Umgebung verfuegbar - deshalb kein Klicktest der UI selbst. Stattdessen wurde der komplette Protokollpfad, den die SPA zur Laufzeit durchlaeuft, per Skript nachgebaut und gegen echte, laufende Instanzen verifiziert:

1. npm run build/npm run lint: fehlerfrei.
2. CORS-Preflight gegen das echte Backend: http://localhost:5173 erlaubt, ein fremder Origin mit 403 abgelehnt.
3. Echter Authorization-Code-+-PKCE-Flow gegen einen echten Keycloak-Container: echte PKCE-Code-Challenge erzeugt, echter Login-Formular-POST, Redirect landet exakt auf http://localhost:5173/callback (der konfigurierten VITE_OIDC_REDIRECT_URI), Code-Tausch am Token-Endpunkt mit passendem Code-Verifier liefert ein echtes JWT - derselbe Ablauf wie oidc-client-tss interne signinRedirect()/ signinRedirectCallback()-Implementierung.
4. Mit diesem echten Token (inkl. Origin-Header wie bei einem Browser-fetch()): echte Police ueber POST /api/policies angelegt, Rollenpruefung real bestaetigt (underwriter-Token bekommt bei cancelPolicy korrekt 403 - deckungsgleich mit canCancelPolicy(roles) in roles.ts, das denselben Button in der UI ausblendet).

Siehe novaris-policy-web-modern-spa/README.md fuer die vollstaendigen Befehle und Ergebnisse.

Real gefundener Port-Konflikt (Umgebungsartefakt, kein Projektfehler)

Bei der Verifikation belegte ein voellig unabhaengiges, gleichzeitig auf derselben Entwicklungsmaschine laufendes Projekt (library-catalog-service) bereits Port 8081 - der sonst im gesamten Projekt dokumentierte Standard-Keycloak-Port. Fuer die Verifikation wurde deshalb einmalig auf Port 8084 ausgewichen (NOVARIS_OIDC_ISSUER_URI/VITE_OIDC_ISSUER per Umgebungsvariable ueberschrieben) - die dokumentierten Standardports (8081 fuer Keycloak) bleiben fuer einen eigenstaendigen Lauf dieses Projekts unveraendert korrekt.

Ehrliche Grenze

• Kein Antragswizard-Frontend (PolicyApplicationController/PolicyApplicationDraft, siehe M2) - nur der direkte PolicyController-Pfad (Police sofort anlegen statt mehrstufigem Wizard) wurde als UI umgesetzt. Waere ein naheliegender naechster Ausbau.
• Produktcodes in einer fixen, redundanten Frontend-Konstante gehalten (siehe SPA-README) statt eines eigenen Backend-Endpunkts nur fuer drei feste Werte.
• Kein Refresh-Token-Flow (siehe 11-oidc-keycloak.md) - bei Token-Ablauf muss sich die Nutzerin erneut einloggen.