Skip to content

Admin Auth v CMS

Tato stránka popisuje, jak je centrální Passkey autorita zapojená přímo do administrace Petrovo CMS.

Navazuje na Auth Passkey Autorita, která řeší samotné ověření identity.

Co se změnilo v administraci

  • lokální hesla byla odstraněna
  • tabulka admin používá jako identitu unikátní email
  • CMS už neověřuje heslo, ale přijímá JWT z auth serveru
  • po přihlášení si CMS vede vlastní session a vlastní oprávnění

Migrace app/migrations/20260509.sql:

  • nastavuje email jako NOT NULL
  • přidává unikátní index na email
  • maže sloupce password a name

Přihlašovací tok

Request do /ADMIN/*
  → authAdminMiddleware zjistí, že není session
  → redirect na /ADMIN/{lang}/login

/ADMIN/login
  → AuthController::login()
  → redirect na AUTH_URL/?redirect=https://host/ADMIN/login&locale=lang

Auth server
  → provede Passkey login
  → redirect zpět na /ADMIN/login?token=<jwt>

Callback v CMS
  → AuthClient::verifyJwt()
  → UserService::getAdminInfoByEmail(email z tokenu)
  → Session::set('admin', id)
  → Session::set('admin_jwt', token)
  → redirect na afterLoginUrl

Pokud token neprojde ověřením, email neexistuje, nebo je admin neaktivní, login skončí chybou a uživatel se vrátí na login route.

Kde v kódu to žije

  • app/Modules/Admin/Auth/AuthController.php
  • app/Integrations/Auth/AuthClient.php
  • app/Middlewares/Auth/authAdminMiddleware.php
  • app/Middlewares/Session/sessionExpirationAdminMiddleware.php
  • app/Modules/Admin/User/UserService.php

Co si drží CMS samo

Auth server neřeší oprávnění do administrace. CMS si po úspěšném loginu samo načítá:

  • admin.id
  • admin.group_id
  • level
  • permissions
  • permissions_editing
  • superadmin

Tedy: auth server potvrzuje identitu, ale autorizace je pořád lokální záležitost Petrovo CMS.

Callback a párování identity

Zásadní je email:

  • auth server vrátí email v JWT
  • CMS hledá přes UserService::getAdminInfoByEmail()
  • bez odpovídajícího emailu v tabulce admin se nikdo nedostane dovnitř

To znamená, že změna emailu v CMS musí odpovídat tomu, co uživatel používá na auth serveru.

Chování login stránky

/ADMIN/login už není klasický formulář:

  • bez query tokenu rovnou přesměruje na auth server
  • při chybě vykreslí fallback stránku s hláškou a retry odkazem
  • s ?token= zpracuje callback a založí session

Odhlášení

POST /ADMIN/logout:

  • smaže admin
  • smaže admin_jwt
  • smaže chybovou hlášku
  • regeneruje session

Pak je uživatel mimo CMS session, ale centrální auth autorita může mít stále vlastní aktivní relaci. Další login proto může být pro uživatele velmi rychlý.

Stránka logged-out

Po odhlášení existuje i route:

GET /ADMIN/logged-out

Je to veřejná stránka bez požadavku na aktivní admin session a slouží jako potvrzovací mezikrok po odhlášení.

Chování:

  • middleware ji pouští bez přihlášení
  • AuthController::loggedOut() vykreslí jednoduchou stránku
  • stránka nabízí návrat na /ADMIN/{lang}/login

To je užitečné hlavně v passkey režimu, kde „odhlášení z CMS“ a „odhlášení z centrální autority“ nejsou totéž.