Docker-Images bauen und veröffentlichen / build (, omsorgCore/Dockerfile, omsorgcore) (push) Successful in 14s
Docker-Images bauen und veröffentlichen / build (, omsorgWeb/Dockerfile, omsorgweb) (push) Successful in 5s
Docker-Images bauen und veröffentlichen / build (, omsorgapp/Dockerfile, omsorgapp) (push) Successful in 17s
The cookie-only refresh-token migration earlier this session broke both mitarbeiter-app and mitarbeiter-app-legacy: they're server-to-server PHP clients (cURL/Guzzle calling omsorgCore directly) with no browser cookie jar, so dropping refreshToken from the login/refresh response body left them with nothing to store - login appeared to succeed, redirected to the dashboard, but the very next page's session check failed silently (mitarbeiter-app's _ensure_fresh_token() bails out whenever $_SESSION['omsorgcore_refresh_token'] is empty), bouncing the user back to the login form every time. Fix: dual-mode refresh token transport instead of cookie-only. - LoginResponse includes refreshToken again (restores the pre-migration contract PHP already expected) alongside the HttpOnly cookie. - AuthController.Refresh/Logout accept an optional body-carried RefreshRequest/LogoutRequest as a fallback: cookie is checked first (browser/omsorgapp), body second (server-to-server clients). - omsorgapp keeps ignoring the body's refreshToken and relies solely on the cookie (XSS-safe) - only its authApi.js needed a small update since the regenerated client now requires an explicit (empty) parameter object for refresh/logout. - Regenerated omsorgcore-client-ts; api-client-php's lib/ was already consistent (never regenerated during the original migration, so it still expected refreshToken all along - only the backend had stopped providing it). Verified end-to-end against a live instance: PHP login+refresh via omsorgcore_login()/omsorgcore_refresh(), and the browser cookie-only flow via curl with Origin/credentials headers - both work. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>