Если пользователя выбрасывает из кабинета во время работы, сначала выясните, что завершилось: cookie в браузере, серверная сессия или авторизация у внешнего провайдера. Не увеличивайте таймаут наугад — одинаковый симптом дают разные причины.
Короткий путь: зафиксируйте точное время выхода, сравните его с idle- и absolute timeout, проверьте атрибуты cookie, а затем убедитесь, что все серверы видят одно хранилище сессий. Так можно отделить штатную политику безопасности от сбоя.
Определите сценарий до изменения настроек
Повторите проблему на тестовой учётной записи и запишите, что происходило перед выходом.
| Наблюдение | Что проверять | |---|---| | Выход после бездействия | Таймаут неактивности и запросы, которые считаются активностью | | Выход через похожий интервал даже при работе | Абсолютный срок сессии или срок токена | | Ошибка только при сохранении формы | CSRF-токен, область cookie или правило для запроса | | Выход возникает не каждый раз | Узлы приложения, хранилище сессий, обновление токена | | Проблема началась после релиза | Смена ключа, очистка хранилища или новая конфигурация |
Повторите тест в обычном и приватном окне; не делайте вывод по одной попытке.
Порядок диагностики
1. Найдите последний успешный и первый неуспешный запрос
Откройте инструменты разработчика, включите сохранение журнала Network и повторите сценарий. Запишите время с часовым поясом, адрес и метод запроса, HTTP-код, редирект и наличие заголовка Set-Cookie.
Значения session cookie, Authorization и токенов копировать в задачу или переписку нельзя. Для сравнения достаточно имени cookie, её атрибутов, безопасного идентификатора запроса и отметки, был ли идентификатор сессии отправлен.
Если на страницу входа перенаправляет JavaScript, сетевой журнал покажет исходный ответ API. Серверный редирект или 401 нужно разбирать на стороне авторизации и сессии, а не только во фронтенде.
2. Проверьте срок и область действия cookie
Сравните cookie до входа, во время работы и после выхода. Проверьте Expires или Max-Age, Domain, Path, Secure и SameSite.
Cookie может оставаться в браузере, хотя сервер уже удалил связанную с ней сессию. Бывает и наоборот: состояние на сервере существует, но браузер не отправляет cookie на нужный поддомен, путь или HTTPS-запрос. Наличие cookie само по себе не доказывает, что сессия работает.
Не отключайте Secure или HttpOnly и не задавайте бесконечный срок жизни ради быстрого исправления. Сначала найдите несоответствие между схемой доменов, HTTPS и настройками приложения.
3. Разделите таймаут неактивности и абсолютный срок
Idle timeout завершает сессию, когда сервер не видит действий заданное время. Absolute timeout ограничивает общую продолжительность сессии независимо от активности. Оба ограничения должны проверяться на сервере.
Проведите два теста. В первом регулярно выполняйте действие, которое приложение учитывает как активность. Во втором оставьте кабинет без запросов дольше настроенного idle timeout. Если оба сценария завершаются в один момент относительно входа, проверьте абсолютный срок или срок внешнего токена.
Уточните, какой слой задаёт каждое ограничение: приложение, фреймворк, хранилище сессий, прокси или провайдер входа. Самый короткий действующий срок часто и определяет поведение пользователя.
4. Проверьте хранилище на всех узлах
Если запросы распределяются между серверами, каждый узел закрытого раздела должен находить состояние сессии. Локальное хранение на одном узле делает результат зависимым от маршрута запроса и перезапусков.
Добавьте в безопасный технический лог идентификатор узла и причину завершения. Идентификатор сессии в открытом виде логировать не следует: используйте необратимую отметку, достаточную для сопоставления событий.
Проверяйте на стенде или одним контролируемым сценарием. Цель — доказать одинаковое поведение узлов, а не менять балансировку рабочего сайта наугад.
5. Исключите гонку обновления и штатный выход
Приложение может обновлять идентификатор сессии или токен. При нескольких вкладках и параллельных запросах сравните, не приходят ли конкурирующие Set-Cookie и какой ответ браузер обрабатывает последним. Отдельно проверьте, считаются ли фоновые запросы активностью.
Сессия также может завершаться намеренно после смены пароля, изменения роли, входа с другого устройства, ограничения одновременных входов или истечения сессии у внешнего провайдера. Журнал аудита должен отличать эти причины от «сессия не найдена» и внутренней ошибки.
Если выход происходит только у одной роли или после одного действия, проверяйте правила доступа и обработчик этого маршрута. Увеличение общего таймаута здесь не поможет.
Как проверить исправление
После изменения повторите исходный сценарий и убедитесь, что:
- активная работа продолжается в пределах документированной политики;
- выход по бездействию происходит предсказуемо;
- абсолютный срок не сбрасывается случайным фоновым запросом;
- разные узлы дают одинаковый результат;
- обновление идентификатора не разрывает параллельные запросы;
- журнал показывает причину без cookie, токенов и персональных данных.
Для долго заполняемой формы полезно заранее предупреждать об окончании сессии и безопасно сохранять черновик. Это уменьшает риск потерять работу, но не заменяет серверную проверку срока.
Что покажет мониторинг, а что останется внутри приложения
Внешняя проверка подтвердит, что публичная страница входа или health endpoint открывается и отвечает ожидаемым кодом. Она не входит в личный кабинет и не доказывает, что приватная сессия конкретного пользователя сохраняется.
Web-Puls можно использовать для контроля публичной точки входа и доступности сайта, а причины выхода искать по серверным событиям и воспроизводимому сценарию. Не передавайте сервису мониторинга приватные URL с токенами, cookie или данными пользователя.
Что собрать для следующего шага
Если причина не найдена, подготовьте время сбоя с часовым поясом, роль пользователя, безопасный URL без секретов, последовательность действий, браузер, первый неуспешный HTTP-код, идентификатор узла и последние изменения конфигурации или релиза.
Начните с временной шкалы, затем сверяйте cookie, серверные таймауты и хранилище. После исправления добавьте публичную точку входа в регулярный мониторинг: это поможет отличить общую недоступность сайта от ошибки управления сессией.