Průřezové nálezy¶

Nálezy, které se netýkají jednoho zdroje, ale všech endpointů.

Prověřeno proti commitu: f1da785 (21. 9. 2026)

Testy: backend/tests/Feature/Audit/PrurezoveAuditTest.php

PRU-01 — Deaktivovaný zaměstnanec zůstává přihlášený (vysoká)¶

Stav: otevřený

Test: PRU-01: deaktivovaný zaměstnanec s platnou session nemá přístup k API

Ověřený fakt — AuthMiddleware::findUser() načte is_active, ale nikde ho nekontroluje. AuthSessionService::validateAccessToken() kontroluje jen stav firmy. Deaktivace v UserController zneplatní passkeys, ale nesmaže session v tabulce sessions.

Dopad — propuštěný zaměstnanec s otevřeným prohlížečem dál pracuje s kartotékou.

PRU-02 — Deaktivovaný zaměstnanec si session prodlužuje refreshem (vysoká)¶

Stav: otevřený

Test: PRU-02: deaktivovaný zaměstnanec si neprodlouží session refreshem

Ověřený fakt — AuthSessionService::refreshSession() nekontroluje is_active a při každém refreshi posune expires_at.

Dopad — spolu s PRU-01 nemá přístup deaktivovaného účtu konec, dokud se refresh volá aspoň jednou za 7 dní.

PRU-03 — Frontend při odmítnutí zkouší veřejnou routu (architektura)¶

Stav: otevřený, bez testu (jde o návrh frontendu, ne o chování API)

Ověřený fakt — react_dev/src/api/base44Client.js, metody list a filter: když interní routa vrátí 401/403, stejný dotaz se zopakuje na /api/public/.... Veřejná, nebo interní routa se navíc volí podle URL stránky (/client, /therapistportal), ne podle přihlášené identity.

Dopad — aby portály fungovaly, přibývají entity do veřejného listu. Odtud pochází SET-01, REZ-03 a REZ-05. Každá nová entita ve veřejném listu je potenciální únik.

Odvozeno — portály potřebují vlastní endpointy s pevným subjektem („moje rezervace“, „můj kalendář terapeuta“), ne obecný CRUD s filtrem z klienta. Je to architektonické rozhodnutí pro autora aplikace, ne oprava jednoho místa.