Как живет сессия

Что проверяют

Понимаете ли вы, как приложение узнаёт вас на каждом запросе, если HTTP сам состояния не хранит. Для тестировщика это основа проверок авторизации. Следом просят назвать тест-кейсы на сессию или объяснить, чем сессия отличается от cookie.

Как отвечать

Опишите жизненный цикл по шагам:

• создание: при логине (иногда уже при первом визите, например ради корзины) сервер заводит запись сессии в памяти, Redis или базе и генерирует случайный идентификатор;
• передача: идентификатор уходит браузеру в Set-Cookie, например JSESSIONID или PHPSESSID, с атрибутами HttpOnly (не видна из JavaScript), Secure (только HTTPS), SameSite (защита от CSRF);
• использование: браузер сам прикладывает cookie к запросам, сервер находит по ней сессию;
• истечение: есть тайм-аут бездействия (в Tomcat по умолчанию 30 минут) и иногда абсолютный срок жизни. Cookie без Expires и Max-Age живёт до закрытия браузера, но серверную сессию это не удаляет;
• завершение: при выходе сервер обязан уничтожить сессию у себя, а не только стереть cookie.

При токенах вроде JWT состояние лежит в самом токене и отозвать его сложнее, поэтому access-токен делают коротким, а refresh-токен хранят и отзывают на сервере.

Сразу назовите проверки: старая cookie после выхода даёт 401 или редирект на логин; после входа идентификатор меняется (защита от фиксации сессии); смена пароля завершает сессии на других устройствах; тайм-аут срабатывает; кнопка «Назад» после выхода не открывает закрытые страницы. Атрибуты cookie видны в DevTools на вкладке Application.

Где спотыкаются

Отождествляют сессию и cookie. Cookie только переносит идентификатор, данные сессии живут на сервере.

Говорят, что закрытие браузера завершает сессию. На сервере она живёт до тайм-аута, а браузеры ещё и восстанавливают сессионные cookie вместе со вкладками.

Проверяют выход только по интерфейсу. Стоит повторить запрос со скопированной до выхода cookie через Postman, и часто выясняется, что сессия на сервере жива.