Ролі та можливості
Матриця показує, що може робити кожна роль і як саме це забезпечено в коді. Основою є docs/reference/template-role-capability-matrix.md. Кожен рядок звірено з http-routes.ts, ws-routes.ts і роутером фронтенду router/index.ts.
Як визначається роль
- Anonymous: немає валідної сесії,
context.auth.getUserId()повертаєnull. - Authenticated user: сесію відновив
session_web.auth-guard.tsповертає401, якщоauth.check()хибне. - Admin:
admin-guard.tsзавантажує користувача з БД і пропускає далі тільки приuser.role === 'admin'(інакше403). Фронтенд перевіряє те саме поле:isAdmin()уstores/user.tsповертаєuser.role === 'admin'. WS-підписка на адмін-канал теж перевіряєuserData.role !== "admin"вadmin-ws-channel-service.ts. - Developer/QA і Operator у коді як ролі не існують. Це люди з доступом до локального оточення,
.env, БД і деплою.
Окремого прапорця адміна немає: колонку is_admin прибрала міграція 20261024171546_drop_users_is_admin, тож єдине джерело — users.role ('user' | 'admin').
Матриця
Позначки: «Так», «Ні», «—» (не застосовно). Middleware session_web і csrf_guard підключені до всіх груп, крім /ping, тому в колонці «Як забезпечено» їх не повторюємо.
| Можливість | Anonymous | User | Admin | Як забезпечено в коді |
|---|---|---|---|---|
| Публічні сторінки (login, register, політики) | Так | Так | Так | Маршрути фронтенду без meta.requiresAuth (/, /login, /register, /verify-email, /reset-password, /about, /privacy-policy, /terms, /cookies, /ai-policy) |
| Реєстрація / вхід / скидання пароля | Так | — | — | Група auth: /register/*, /login, /forgot-password, /reset-password, /reset-phone/*, /verify-email без auth_guard. Гостьові маршрути не відхиляють уже залогінених: «—» означає «не потрібно», а не «заборонено» |
| OAuth-вхід | Так | — | — | Група auth/oauth: /:provider/redirect, /:provider/callback без auth_guard |
| Вихід, зміна пароля | Ні | Так | Так | auth_guard на /auth/logout, /auth/logout-all, /auth/change-password |
| Захищена оболонка застосунку | Ні | Так | Так | Бекенд: auth_guard на /main/init, /main/update-ws-token. Фронтенд: meta.requiresAuth на /account, /support, редірект на /login |
| Прив'язка телефону / email | Ні | Так | Так | auth_guard на /auth/link-phone/start, /auth/link-phone/confirm, /auth/link-email/start, /auth/resend-verification-email |
| Оновлення акаунта / профілю | Ні | ? | ? | Окремого маршруту оновлення профілю в http-routes.ts немає (див. попередження нижче) |
| Завантаження / видалення аватара | Ні | Так | Так | Група avatar з auth_guard |
| Support chat | Ні | Так | Так | HTTP: група support з auth_guard. WS: support_open_chat, support_chat (WS-з'єднання потребує WS-токен, який видається лише під auth_guard) |
| Push-підписки | Ні | Так | Так | Група push-subscriptions: auth_guard на кожному маршруті, крім vapid-public-key (доступний анонімно); перевірка getUserId() у push-subscription-controller.ts лишається як додатковий захист |
| Адмін-оболонка | Ні | Ні | Так | Фронтенд: meta: { requiresAuth: true, requiresAdmin: true } на /admin, не-адміна перенаправляє на /account. Бекенд: admin_guard на всіх групах admin |
| Керування базою знань | Ні | Ні | Так | /admin/knowledge-base* з auth_guard + admin_guard; UI /admin/knowledge-base |
| Керування AI-промптами | Ні | Ні | Так* | Група prompts (/, /:type, /:type/test) з auth_guard + admin_guard. *Сторінки для промптів у фронтенд-роутері немає, доступ лише через API |
| Статистика AI usage | Ні | Ні | Так | /admin/usage/text, /admin/usage/stats з admin_guard |
| Користувачі та історія онлайну | Ні | Ні | Так | /admin/users, /admin/users-online*, /admin/history-online з admin_guard. WS-група admin/* з ws_admin_guard (роль з userData з'єднання); admin-ws-channel-service додатково перевіряє role |
| API playground | — | — | — | Не залежить від ролі. /doc/routes доступний будь-кому, але лише при APP_ENV=manual-test, DOC_PAGE=true, SERVE_STATIC=true (server.ts). Див. API Playground |
| Міграції БД, конфігурація, деплой | Ні | Ні | Ні | Не HTTP-можливості: CLI-скрипти (db:*, див. Скрипти) і .env. Доступ визначається доступом до сервера/репозиторію (Developer/QA локально, Operator у production) |
Видалений маршрут POST /main/save-user
Раніше в групі main був анонімний маршрут /main/save-user, який створював користувача з паролем без хешування (п. 65 у списку проблем). Його видалено разом зі схемами SaveUserInput/SaveUserResponse, WSSaveUserPayload і клієнтським api.saveUser. Користувачі створюються лише через реєстрацію (email або телефон) та OAuth — див. Автентифікація і Вхід через соцмережі.
Не підтверджено
Рядок «Update account/profile» з вихідної матриці не має окремого backend-маршруту в http-routes.ts. Сторінка /account існує, але, судячи з маршрутів, з профілем працюють тільки аватар, прив'язка телефону/email і зміна пароля. Колонки Developer/QA та Operator з вихідної матриці («Test», «Configure») описують організаційні обов'язки і кодом не забезпечуються, тому в таблицю вище їх не включено.
Докладніше про guards див. Автентифікація і Middleware.