Login + Registrierung im Antragsprüfer statt Keycloak-Redirect #129

New Issue

tobias · 2026-04-12T15:53:49+02:00

tobias commented

2026-04-12 15:53:49 +02:00

Kontext

Aktuell leitet der "Anmelden"-Button zum Keycloak-Login-UI weiter (externes Redirect). "Registrieren" öffnet ein eigenes Modal im Antragsprüfer, das via Keycloak Admin-API den User anlegt. Das ergibt eine inkonsistente UX: Login = extern, Registrierung = intern.

Ziel

Login + Registrierung komplett im Antragsprüfer abwickeln. Kein Redirect zu Keycloak. Beides in einem einzigen Modal mit Tab-Wechsel (Login / Registrieren).

Implementierung

POST {keycloak_url}/realms/{realm}/protocol/openid-connect/token
Content-Type: application/x-www-form-urlencoded

grant_type=password
client_id=gwoe-antragspruefer
username={user_input}
password={password_input}

Response: { access_token, refresh_token, expires_in, ... }

→ access_token als Cookie setzen (wie bisher nach Redirect).

Keycloak-Konfiguration

Direct Access Grants müssen im Client gwoe-antragspruefer in Keycloak aktiviert sein:

Realm → Clients → gwoe-antragspruefer → Settings → "Direct Access Grants Enabled" = ON

UI

Hamburger: "Anmelden" und "Registrieren" werden zu einem einzigen Punkt "🔑 Anmelden / Registrieren"
Öffnet ein Modal mit zwei Tabs:
- Login: Username + Password → Direct Access Grant → JWT-Cookie
- Registrieren: Vorname + Nachname + E-Mail + Username → Admin-API → "Freischaltung beantragt"
Nach erfolgreichem Login: Modal schließt, UI aktualisiert (Name anzeigen, Admin-Features)
Bei Fehler: Fehlermeldung im Modal (falsche Credentials, User nicht freigeschaltet, etc.)

Backend

Neuer Endpoint POST /api/auth/login — nimmt username+password, leitet an Keycloak Token-Endpoint weiter, setzt Cookie, gibt User-Info zurück
Bestehender POST /api/auth/register bleibt unverändert
GET /api/auth/login-url kann entfallen (kein Redirect mehr)

Sicherheit

Direct Access Grant ist OIDC-konform, aber als "nicht bevorzugt" markiert weil Credentials durch die Webapp fließen
OK solange HTTPS (ist gegeben: gwoe.toppyr.de via Let's Encrypt)
Keycloak brute-force protection greift weiterhin (Realm → Security Defenses)

Akzeptanzkriterien

Login-Modal im Antragsprüfer (kein Redirect)
Registrierung im gleichen Modal (Tab-Wechsel)
"Anmelden" + "Registrieren" verschmelzen zu einem Hamburger-Eintrag
Keycloak Direct Access Grant aktiviert
Fehlerbehandlung (falsche Credentials, gesperrter Account, nicht freigeschaltet)
Refresh-Token-Handling (Token-Refresh vor Ablauf)

## Kontext Aktuell leitet der "Anmelden"-Button zum Keycloak-Login-UI weiter (externes Redirect). "Registrieren" öffnet ein eigenes Modal im Antragsprüfer, das via Keycloak Admin-API den User anlegt. Das ergibt eine inkonsistente UX: Login = extern, Registrierung = intern. ## Ziel Login + Registrierung komplett im Antragsprüfer abwickeln. Kein Redirect zu Keycloak. Beides in einem einzigen Modal mit Tab-Wechsel (Login / Registrieren). ## Implementierung ### Login via Direct Access Grant ``` POST {keycloak_url}/realms/{realm}/protocol/openid-connect/token Content-Type: application/x-www-form-urlencoded grant_type=password client_id=gwoe-antragspruefer username={user_input} password={password_input} ``` Response: `{ access_token, refresh_token, expires_in, ... }` → `access_token` als Cookie setzen (wie bisher nach Redirect). ### Keycloak-Konfiguration Direct Access Grants müssen im Client `gwoe-antragspruefer` in Keycloak aktiviert sein: - Realm → Clients → gwoe-antragspruefer → Settings → "Direct Access Grants Enabled" = ON ### UI - Hamburger: "Anmelden" und "Registrieren" werden zu einem einzigen Punkt **"🔑 Anmelden / Registrieren"** - Öffnet ein Modal mit zwei Tabs: - **Login**: Username + Password → Direct Access Grant → JWT-Cookie - **Registrieren**: Vorname + Nachname + E-Mail + Username → Admin-API → "Freischaltung beantragt" - Nach erfolgreichem Login: Modal schließt, UI aktualisiert (Name anzeigen, Admin-Features) - Bei Fehler: Fehlermeldung im Modal (falsche Credentials, User nicht freigeschaltet, etc.) ### Backend - Neuer Endpoint `POST /api/auth/login` — nimmt username+password, leitet an Keycloak Token-Endpoint weiter, setzt Cookie, gibt User-Info zurück - Bestehender `POST /api/auth/register` bleibt unverändert - `GET /api/auth/login-url` kann entfallen (kein Redirect mehr) ### Sicherheit - Direct Access Grant ist OIDC-konform, aber als "nicht bevorzugt" markiert weil Credentials durch die Webapp fließen - OK solange HTTPS (ist gegeben: gwoe.toppyr.de via Let's Encrypt) - Keycloak brute-force protection greift weiterhin (Realm → Security Defenses) ## Akzeptanzkriterien - [ ] Login-Modal im Antragsprüfer (kein Redirect) - [ ] Registrierung im gleichen Modal (Tab-Wechsel) - [ ] "Anmelden" + "Registrieren" verschmelzen zu einem Hamburger-Eintrag - [ ] Keycloak Direct Access Grant aktiviert - [ ] Fehlerbehandlung (falsche Credentials, gesperrter Account, nicht freigeschaltet) - [ ] Refresh-Token-Handling (Token-Refresh vor Ablauf)

tobias commented

2026-04-20 02:00:12 +02:00

Code fertig — Deploy wartet auf Keycloak-Config

Was umgesetzt ist (lokal, nicht deployed):

Backend

Neuer Endpoint POST /api/auth/login — nimmt username+password, ruft Keycloak Direct Access Grant, setzt access_token als HttpOnly-Cookie
Neuer Endpoint POST /api/auth/refresh — liest rt-Cookie, tauscht gegen neuen access_token
Fehler-Mapping: 401 → invalid_credentials, andere → unknown
access_token-Cookie jetzt HttpOnly (vorher war es HttpOnly=False — verifiziert dass JS es nicht lesen musste außer für Clear-on-Logout, das funktioniert weiter via path-based delete)

Frontend

Hamburger-Button "🔑 Anmelden / Registrieren" statt getrennte Anmelden/Registrieren
Neues Modal auth-modal mit Tabs Login/Register
Login-Tab: Username+Password → fetch /api/auth/login → Modal schließen, UI refresh
Register-Tab: bestehender Flow unverändert (Admin-API-basiert)
Fehler im Modal als sichtbare Meldung

Tests

tests/test_auth.py +4 Tests für direct_login() — alle grün
Unit-Suite: 390 → 394 passed

🔴 VORAUSSETZUNG — Keycloak-Konfiguration (vor Deploy!)

Ohne diese Änderung wird ausnahmslos jeder Login-Versuch mit HTTP 400 fehlschlagen:

Keycloak Admin-UI öffnen
Realm gwoe (oder wie konfiguriert) auswählen
Clients → gwoe-antragspruefer auswählen
Tab Capability config (oder Settings je nach Keycloak-Version)
Direct access grants auf ON stellen
Save

Keine Code-Änderung. Einmalige Admin-Aktion.

Deploy-Plan

User bestätigt: Direct Access Grants in Keycloak aktiviert
Ich deploye die Änderungen
Smoke-Test: POST /api/auth/login mit Test-User
Issue schließen

Nachlauf-Aufgaben (eigene Folge-Issues wenn relevant)

Automatisches Token-Refresh client-seitig (vor expires_in /api/auth/refresh aufrufen) — aktuell läuft access_token einfach aus, User muss sich neu anmelden
Brute-force-Protection im Keycloak-Realm prüfen (Realm → Security Defenses)

Deploy-Risiko

Bestehende Nutzer werden beim nächsten Request automatisch auf neuen Cookie-State migriert (access_token wird erneuert via normaler Flow). Kurzer "Neu-Login nötig"-Effekt für aktive Sessions
Wenn Keycloak-Config NICHT gesetzt: 100% Login-Fehler. Darum vorher bestätigen.

Sag Bescheid, wenn Keycloak-Config fertig ist — dann deploy ich.

## Code fertig — Deploy wartet auf Keycloak-Config **Was umgesetzt ist (lokal, nicht deployed):** ### Backend - Neuer Endpoint `POST /api/auth/login` — nimmt `username`+`password`, ruft Keycloak Direct Access Grant, setzt `access_token` als HttpOnly-Cookie - Neuer Endpoint `POST /api/auth/refresh` — liest `rt`-Cookie, tauscht gegen neuen `access_token` - Fehler-Mapping: 401 → `invalid_credentials`, andere → `unknown` - `access_token`-Cookie jetzt `HttpOnly` (vorher war es `HttpOnly=False` — verifiziert dass JS es nicht lesen musste außer für Clear-on-Logout, das funktioniert weiter via path-based delete) ### Frontend - Hamburger-Button "🔑 Anmelden / Registrieren" statt getrennte Anmelden/Registrieren - Neues Modal `auth-modal` mit Tabs Login/Register - Login-Tab: Username+Password → fetch `/api/auth/login` → Modal schließen, UI refresh - Register-Tab: bestehender Flow unverändert (Admin-API-basiert) - Fehler im Modal als sichtbare Meldung ### Tests - `tests/test_auth.py` +4 Tests für `direct_login()` — alle grün - Unit-Suite: 390 → 394 passed ## 🔴 VORAUSSETZUNG — Keycloak-Konfiguration (vor Deploy!) Ohne diese Änderung wird ausnahmslos **jeder Login-Versuch** mit HTTP 400 fehlschlagen: 1. Keycloak Admin-UI öffnen 2. Realm `gwoe` (oder wie konfiguriert) auswählen 3. **Clients** → `gwoe-antragspruefer` auswählen 4. Tab **Capability config** (oder **Settings** je nach Keycloak-Version) 5. **Direct access grants** auf **ON** stellen 6. **Save** Keine Code-Änderung. Einmalige Admin-Aktion. ## Deploy-Plan - [ ] User bestätigt: Direct Access Grants in Keycloak aktiviert - [ ] Ich deploye die Änderungen - [ ] Smoke-Test: `POST /api/auth/login` mit Test-User - [ ] Issue schließen ## Nachlauf-Aufgaben (eigene Folge-Issues wenn relevant) - Automatisches Token-Refresh client-seitig (vor `expires_in` `/api/auth/refresh` aufrufen) — aktuell läuft access_token einfach aus, User muss sich neu anmelden - Brute-force-Protection im Keycloak-Realm prüfen (Realm → Security Defenses) ## Deploy-Risiko - Bestehende Nutzer werden beim nächsten Request automatisch auf neuen Cookie-State migriert (access_token wird erneuert via normaler Flow). Kurzer "Neu-Login nötig"-Effekt für aktive Sessions - Wenn Keycloak-Config NICHT gesetzt: 100% Login-Fehler. Darum vorher bestätigen. **Sag Bescheid, wenn Keycloak-Config fertig ist — dann deploy ich.**

tobias commented

2026-04-20 03:04:25 +02:00

Live — Keycloak Direct Access Grants bereits aktiv

Unerwarteter Befund: Beim Zugriff via Admin-API zeigt sich directAccessGrantsEnabled: True bereits gesetzt auf Client gwoe-antragspruefer (Realm collaboration). Entweder User hat das vorher schon aktiviert, oder es war ohnehin default.

Deploy-Status: Der #129-Code (Direct-Login-Modal + POST /api/auth/login + POST /api/auth/refresh) ist bereits live:

POST /api/auth/login → 401 bei falschen Credentials (Route aktiv, Keycloak-Integration antwortet korrekt)
POST /api/auth/refresh → 401 ohne rt-Cookie (erwartet)
/classic enthält den Modal-Code: auth-modal, auth-tab-login, auth-tab-register, Hamburger-Button 🔑 Anmelden / Registrieren

Ist getestet: 394 → 422 lokale Tests passed. Der Login-Flow hat Unit-Coverage (4 neue Tests in test_auth.py).

Noch offen (Follow-up):

Client-seitiges auto-Refresh vor Token-Ablauf (gerade läuft token einfach aus)
Login-Modal auch im v2-Frontend einbauen (aktuell ist v2-Default nur mit Login via /classic möglich — also klick aufs Hamburger-Menü dort, zurück ins v2). Der Flow ist hässlich.

Schließe nach Nachtest durch dich. Wenn alles läuft wie gedacht, Nachschliff in eigenem Issue.

## Live — Keycloak Direct Access Grants bereits aktiv **Unerwarteter Befund:** Beim Zugriff via Admin-API zeigt sich `directAccessGrantsEnabled: True` bereits gesetzt auf Client `gwoe-antragspruefer` (Realm `collaboration`). Entweder User hat das vorher schon aktiviert, oder es war ohnehin default. **Deploy-Status:** Der #129-Code (Direct-Login-Modal + `POST /api/auth/login` + `POST /api/auth/refresh`) ist bereits live: - `POST /api/auth/login` → 401 bei falschen Credentials (Route aktiv, Keycloak-Integration antwortet korrekt) - `POST /api/auth/refresh` → 401 ohne rt-Cookie (erwartet) - `/classic` enthält den Modal-Code: `auth-modal`, `auth-tab-login`, `auth-tab-register`, Hamburger-Button `🔑 Anmelden / Registrieren` **Ist getestet:** 394 → 422 lokale Tests passed. Der Login-Flow hat Unit-Coverage (4 neue Tests in `test_auth.py`). **Noch offen (Follow-up):** - Client-seitiges auto-Refresh vor Token-Ablauf (gerade läuft token einfach aus) - Login-Modal auch im v2-Frontend einbauen (aktuell ist v2-Default nur mit Login via `/classic` möglich — also klick aufs Hamburger-Menü dort, zurück ins v2). Der Flow ist hässlich. Schließe nach Nachtest durch dich. Wenn alles läuft wie gedacht, Nachschliff in eigenem Issue.

tobias commented

2026-04-20 22:07:12 +02:00

Code + Deploy fertig. Zum Schließen kurz browser-testen:

https://gwoe.toppyr.de/ öffnen (nicht eingeloggt)
Topbar rechts: Button „Anmelden"
Modal öffnet → Tab „Anmelden" → Keycloak-Credentials eingeben
Erwartung: Modal schließt, Seite reloadet, in der Topbar steht dein Name + Abmelden-Button
Klick Abmelden → Cookie weg, reload, Anmelden-Button wieder da

Wenn alles läuft: Issue closen. Wenn was hakt: Screenshot/Error hier. Gerne morgen.

Code + Deploy fertig. Zum Schließen kurz browser-testen: 1. https://gwoe.toppyr.de/ öffnen (nicht eingeloggt) 2. Topbar rechts: Button „Anmelden" 3. Modal öffnet → Tab „Anmelden" → Keycloak-Credentials eingeben 4. Erwartung: Modal schließt, Seite reloadet, in der Topbar steht dein Name + Abmelden-Button 5. Klick Abmelden → Cookie weg, reload, Anmelden-Button wieder da Wenn alles läuft: Issue closen. Wenn was hakt: Screenshot/Error hier. Gerne morgen.

tobias added this to the 1.0 milestone 2026-04-25 20:59:55 +02:00

tobias referenced this issue from a commit

2026-04-25 21:01:28 +02:00

feat(#139,#129,#138,#141): v2-Frontend (ECOnGOOD-CD), Login-Modal, Auto-DL, OG-Cards

tobias commented

2026-04-25 21:09:29 +02:00

Login bestätigt durch User. Registration sendet keine Mail bei Anlage — das ist intendiertes Design (User wird mit enabled=false angelegt, erst nach Admin-Freischaltung schickt Keycloak die „Passwort-setzen"-Mail). Optional könnte noch eine Bestätigungsmail „Registrierung eingegangen" direkt beim Anlegen geschickt werden — kleines UX-Folge-Issue, kein Blocker.

Schließe das Hauptticket.

Login bestätigt durch User. Registration sendet keine Mail bei Anlage — das ist intendiertes Design (User wird mit `enabled=false` angelegt, erst nach Admin-Freischaltung schickt Keycloak die „Passwort-setzen"-Mail). Optional könnte noch eine Bestätigungsmail „Registrierung eingegangen" direkt beim Anlegen geschickt werden — kleines UX-Folge-Issue, kein Blocker. Schließe das Hauptticket.

tobias closed this issue

2026-04-25 21:09:29 +02:00

tobias referenced this issue

2026-04-25 21:09:30 +02:00

Registrierungs-Bestätigung per Mail an User direkt nach Anmeldung #143

Sign in to join this conversation.