8 Commits
Author SHA1 Message Date
Felix KemmlerandClaude Sonnet 5 09dce2ab98 Fix broken login on omsorgWeb: restore refreshToken in auth responses
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>
2026-08-10 19:02:16 +02:00
Felix KemmlerandClaude Sonnet 5 dca0349e8c Actually commit api-client-php's vendor/ - it was silently gitignored
Docker-Images bauen und veröffentlichen / build (, omsorgCore/Dockerfile, omsorgcore) (push) Successful in 3s
Docker-Images bauen und veröffentlichen / build (, omsorgWeb/Dockerfile, omsorgweb) (push) Successful in 6s
Docker-Images bauen und veröffentlichen / build (, omsorgapp/Dockerfile, omsorgapp) (push) Successful in 4s
omsorgCore/CLAUDE.md documents vendor/ as committed so the app can run
without a composer install step, but the generator's own .gitignore
(api-client-php/.gitignore) excludes /vendor/ - it only ever existed
untracked on disk locally, which is why the Docker build worked for me
but mitarbeiter-app crashed at runtime on a real (fresh-checkout) deploy:
"Failed opening required '.../api-client-php/vendor/autoload.php'".
Verified by building from a git-archive-simulated fresh checkout with
this fix applied - mitarbeiter-app's login page now renders without the
fatal error.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-10 18:51:21 +02:00
Felix KemmlerandClaude Sonnet 5 0d767d7edf Fix infinite redirect loop on omsorgWeb behind the TLS-terminating proxy
Docker-Images bauen und veröffentlichen / build (, omsorgCore/Dockerfile, omsorgcore) (push) Successful in 3s
Docker-Images bauen und veröffentlichen / build (, omsorgWeb/Dockerfile, omsorgweb) (push) Successful in 4s
Docker-Images bauen und veröffentlichen / build (, omsorgapp/Dockerfile, omsorgapp) (push) Successful in 3s
The root .htaccess forces HTTPS via `RewriteCond %{HTTPS} !=on`. Behind a
reverse proxy that terminates TLS and forwards to Apache over plain HTTP,
%{HTTPS} is always "off" - verified via mod_rewrite trace logging that
this is NOT spoofable via SetEnvIf or a RewriteRule E-flag, despite that
being commonly recommended; %{HTTPS} reflects only the actual TLS
connection to Apache. Every request was therefore redirected to https://,
which the proxy forwarded back over HTTP, looping forever (browser: "the
page isn't redirecting properly").

Fix: .htaccess's redirect condition also accepts a trusted
X-Forwarded-Proto: https header as evidence the request is already
HTTPS. omsorgWeb/docker/000-default.conf additionally sets HTTPS=on in
the request environment when that header is present, so mod_headers'
`env=HTTPS` condition (HSTS header) still fires correctly - this part
doesn't affect mod_rewrite's %{HTTPS} but is unrelated to the redirect fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-10 18:37:06 +02:00
Felix KemmlerandClaude Sonnet 5 2a05c791f5 Use registry images in compose, drop MySQL/named volumes, fix omsorgWeb build
Docker-Images bauen und veröffentlichen / build (, omsorgCore/Dockerfile, omsorgcore) (push) Successful in 3s
Docker-Images bauen und veröffentlichen / build (, omsorgWeb/Dockerfile, omsorgweb) (push) Successful in 3s
Docker-Images bauen und veröffentlichen / build (VITE_OMSORG_CORE_URL=${{ vars.OMSORG_CORE_PUBLIC_URL }}, omsorgapp/Dockerfile, omsorgapp) (push) Successful in 3s
- docker-compose.yml: pull omsorgcore/omsorgapp/omsorgweb from the Gitea
  registry (pinnable via OMSORG_IMAGE_TAG) instead of building locally;
  remove the MySQL service (mitarbeiter-app-legacy is unmaintained legacy
  code) and switch all persistent storage from named Docker volumes to
  bind mounts under /root/data/.
- omsorgWeb/Dockerfile: create the upload/download/etc. directories before
  chown'ing them - they're excluded by .gitignore, so a fresh CI checkout
  doesn't have them and the build failed there (only worked locally because
  of leftover local test files).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-10 17:58:29 +02:00
Felix KemmlerandClaude Sonnet 5 598dfcd38a Migrate omsorgapp to browser SPA, add Docker/CI build setup
Docker-Images bauen und veröffentlichen / build (, omsorgCore/Dockerfile, omsorgcore) (push) Successful in 3s
Docker-Images bauen und veröffentlichen / build (, omsorgWeb/Dockerfile, omsorgweb) (push) Failing after 4s
Docker-Images bauen und veröffentlichen / build (VITE_OMSORG_CORE_URL=${{ vars.OMSORG_CORE_PUBLIC_URL }}, omsorgapp/Dockerfile, omsorgapp) (push) Successful in 3s
- omsorgapp: drop Electron, run as a plain Vite/React browser app; refresh
  token moves to an HttpOnly cookie (omsorgCore), CORS added for the new
  browser origin, document download/preview switched to Blob-based browser
  APIs.
- Add Dockerfiles for omsorgCore, omsorgapp, and omsorgWeb, a docker-compose.yml
  wiring Postgres/MySQL/all three apps together, and a Gitea Actions workflow
  that builds and pushes images to the repo's container registry on push to
  main and on version tags.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-10 17:42:45 +02:00
Felix KemmlerandClaude Sonnet 5 e9e96a57dc Add facilities, contracts, orders, value lists, audit log, and desktop app modules
Extends omsorgCore with full CRUD for Facility/Contract/Order plus
configurable value lists and an audit trail, and wires the omsorgapp
frontend up to the new facilities, settings, and audit-log modules;
includes a sidebar active-nav-item highlight.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-08 23:29:16 +02:00
Felix KemmlerandClaude Sonnet 5 ee74ed65f5 Rebuild OMSORG Connect from scratch: login-only milestone
New omsorgWeb/mitarbeiter-app/ replaces the legacy PHP app for now
with just the login flow, built fresh instead of incrementally
refactored. Reuses the already-working omsorgCore JWT auth pattern
(login, silent refresh, session-stored token pair, /api/auth/me for
role+permissions) but drops everything legacy carried alongside it:
no local MySQL user cache, no admin/user-management endpoints, no
admin UI. Employee/user management stays exclusive to OMSORG Desktop
per architecture decision - Connect only ever acts on the current
user's own session.

logout.php additionally revokes the refresh token server-side via
omsorgcore_logout(), which the legacy version never did.

Verified end-to-end against a running omsorgCore instance: login,
dashboard via /api/auth/me, logout + token revocation, unauth
redirect, and wrong-credential error handling.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-07 14:32:55 +02:00
Felix KemmlerandClaude Sonnet 5 b6c1389c55 Reorganize into monorepo layout, move mitarbeiter-app to legacy reference
Consolidates the previously separate omsorgapp and omsorgCore repos
(each had their own nested .git with GitHub history) plus the old
root-level website/mitarbeiter-app into a single monorepo, matching
the structure already documented in the root CLAUDE.md. Also moves
the PHP employee app aside as omsorgWeb/mitarbeiter-app-legacy/ to
serve as a template for a ground-up rewrite.

Fixes .gitignore in the same pass: the config-secrets/uploads/data
patterns were unanchored (relative to repo root, not depth-agnostic),
so they silently stopped matching once the app moved under omsorgWeb/.
Patterns are now **/-prefixed and cover both mitarbeiter-app and
mitarbeiter-app-legacy, keeping DB/SMTP credentials and uploaded
employee documents out of version control.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-07 14:21:37 +02:00