Stage 8. Sessions
Session-аутентификация строится на понятной модели: сервер хранит состояние входа пользователя, а браузер отправляет только session id. Это не «устаревший подход», а рабочая схема для систем, где нужен жёсткий контроль активных входов, быстрый force logout и централизованный аудит действий.
1. Как работает session-поток
- Пользователь логинится.
- Сервер создаёт запись сессии в хранилище.
- Сервер возвращает session id клиенту (обычно в cookie).
- Браузер прикладывает этот id к следующим запросам.
- Сервер ищет сессию, проверяет TTL и восстанавливает auth-контекст.
Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax
Главное для новичка: в запросе нет всего профиля пользователя, там только идентификатор сессии. Полное состояние остаётся на сервере.
2. Плюсы session-подхода
| Что даёт | Почему это полезно в проде |
|---|---|
| Мгновенная инвалидизация | Можно сразу отключить доступ конкретной сессии |
| Централизованный контроль | Видно активные логины и их контекст |
| Простая модель logout | Не нужно ждать истечения токена, как в JWT |
| Удобный аудит | Легче отслеживать user activity по сессии |
Поэтому session часто выбирают для админок, кабинетов сотрудников, финансовых систем и других сценариев с высокими требованиями к управляемости доступа.
3. Главные риски и где чаще ломается
Самый частый риск — хранить сессии только в памяти одного инстанса, а потом масштабировать приложение горизонтально. Когда пользователь попадает на другую ноду, там может не быть его сессии, и он получает случайный logout.
Вторая распространённая проблема — слабая защита session id: нет HttpOnly, нет Secure, слишком длинный TTL, отсутствует ротация id после логина. Тогда session id проще украсть или переиспользовать.
4. Что хранить в сессии, а что нет
Хорошая практика: в сессии держать минимум данных — userId, роли, технические флаги контекста. Плохая практика: класть большие объектные графы, тяжелые DTO и чувствительные данные. Это увеличивает память, усложняет сериализацию, затрудняет релизы и создает риски утечек.
5. Инфраструктура для стабильной session-модели
- Shared session store (например Redis) для кластера.
- Явный TTL и политика продления сессии.
- Ротация session id после успешного login.
- Симметричная cookie-политика для login/logout.
- Метрики: активные сессии, истечения, forced logout, ошибки store.
Если эти пункты не заданы, система может выглядеть стабильной локально, но деградировать под реальной нагрузкой и распределённым трафиком.
Практический сценарий
Команда вынесла приложение в кластер из трёх нод, но оставила in-memory session storage на каждом инстансе. Пользователи начали «вылетать» из аккаунта случайно: часть запросов попадала на ноду, где не было нужной сессии. Параллельно поддержка видела только симптом «иногда разлогинивает», без технической причины. После перехода на общий session store, добавления метрик по session lookup и нормальной cookie-политики поведение стало предсказуемым. Этот пример показывает: session-модель хорошо работает, если её инфраструктурные требования учтены заранее.