diff --git a/EventHubBackSpec.md b/EventHubBackSpec.md index cfbc2d0..aeb6c88 100644 --- a/EventHubBackSpec.md +++ b/EventHubBackSpec.md @@ -173,8 +173,8 @@ EventHub — платформа для управления событиями - Поддержка 100 000+ пользователей. - Горизонтальное масштабирование добавлением новых узлов. - Все персистентные таблицы хранятся в `disc_copies` на каждом узле (задача #13). -- Сессионные таблицы: `auth_session` (единая модель refresh JWT) хранится в `disc_copies` для кластерной устойчивости. -- Legacy-таблицы `session` и `admin_session` (`ram_copies`) сохранены для пользовательского `/v1/refresh` до фазы 2. +- Сессионные таблицы: `auth_session` (единая модель refresh JWT) в `disc_copies` для user и admin API. +- Legacy-таблицы `session` и `admin_session` (`ram_copies`) сохранены в схеме, user/admin hot path используют `auth_session`. - Индексы созданы для часто запрашиваемых полей (calendar_id, start_time, event_type, status и др.) (задача #13). - Полная репликация горячих таблиц между всеми узлами кластера (задача #14). - Автоматическое обнаружение узлов через DNS-имя `eventhub-node` или статический список (задача #14). @@ -282,10 +282,10 @@ src/ ### Общие принципы - Пользователи и администраторы используют разные эндпоинты и JWT-секреты. - Access-токен — короткоживущий stateless JWT (HS256). -- Refresh-токен — 30 дней; для admin API реализован как подписанный JWT (фаза 1, #23). +- Refresh-токен — 30 дней; подписанный JWT в единой session-модели (`auth_session`). - Все защищённые эндпоинты требуют заголовок `Authorization: Bearer `. -### Единая session-модель (`auth_session`, фаза 1 — admin) +### Единая session-модель (`auth_session`) Таблица Mnesia `auth_session` (`disc_copies`): | Поле | Описание | @@ -304,6 +304,12 @@ src/ - `sid=`, `fid=`, `jti=` - `client=admin`, `exp`, `iat` +**Refresh JWT (user, фаза 2)** — claims: +- `typ=refresh`, `aud=user`, `sub=` +- `sid`, `fid`, `jti` — как у admin +- `client=web` (фаза 3: `mobile`), `exp`, `iat` +- Подпись: `JWT_SECRET` (user JWK), отдельно от admin + **Поток login admin** (`POST /v1/admin/login`): 1. Проверка email/password. 2. Создание записи `auth_session`. @@ -315,13 +321,23 @@ src/ 3. При совпадении — ротация: новый `jti`, новая пара токенов. 4. При несовпадении (reuse) — `revoke_family`, ответ 401. +**Поток login user** (`POST /v1/login`): +1. Проверка email/password. +2. Создание записи `auth_session` (`subject_type=user`, `client_type=web`). +3. Ответ: `{ token, refresh_token, user }`. + +**Поток refresh user** (`POST /v1/refresh`): +1. Верификация refresh JWT (`aud=user`). +2. Сверка `jti` с `current_jti` в Mnesia, ротация при успехе. +3. Reuse — `revoke_family`, 401. + **Фазы внедрения:** - Фаза 1 (#23): admin API — реализовано. -- Фаза 2: user `/v1/refresh` на той же модели. -- Фаза 3: client web + mobile (тот же контракт `{token, refresh_token}`). +- Фаза 2 (#26): user login + `/v1/refresh` — реализовано. +- Фаза 3: client web + mobile (явный `client_type`, тот же контракт). -### Legacy user refresh (до фазы 2) -- `POST /v1/login` + `POST /v1/refresh` используют opaque refresh-токен в таблице `session` (`ram_copies`). +### Legacy (не используется login/refresh user) +- Таблица `session` (`ram_copies`) и opaque refresh в `core_session` — оставлены в кодовой базе, hot path user API переведён на `auth_session`. ## 7. ВЕРСИОНИРОВАНИЕ И СТАТУС Текущая версия: 1.5 (MVP, альфа). Включает: