Почему в devtools не отправился запрос, но авторизация прошла успешно
Что проверяют
Умеете ли вы отличать «события не было» от «инструмент его не показал», и не спешите ли с выводом о баге. Для тестировщика это вопрос про дисциплину расследования, а не про знание панели.
Как отвечать
Развести две гипотезы и проверять их по очереди.
Первая: запрос был, но вы его не видите. Типичные причины: включён фильтр по типу, запись началась позже события, отключено сохранение лога и редирект после входа его очистил, запрос ушёл из iframe или из окна провайдера входа, его отправил Service Worker, обмен идёт по WebSocket и лежит одной строкой, которая не мигает при каждом сообщении.
Вторая: запроса и правда не было, потому что он не нужен. Сессия уже существовала: живая кука, токен в хранилище, тихое обновление токена в скрытом фрейме. Приложение прочитало то, что лежало, и показало кабинет.
Что делать руками: включить сохранение лога и отключение кэша, снять фильтры, посмотреть вкладку Application на куки и хранилище, проверить зарегистрированные Service Workers, переключить контекст фрейма. Если пусто, взять арбитра вне браузера: системный прокси или экспорт сетевого лога, и сверить с логами сервера.
В отчёт идёт разделение: что ожидали, что наблюдали, воспроизводится ли на чистом профиле, какой слой отвечает.
Где спотыкаются
Заводят баг про дыру в безопасности, «вход без обращения к серверу». Вывод про безопасность делается по поведению сервера: проверяется, что происходит с протухшим и с подменённым токеном, а не то, пусто ли в панели.
Второе: забывают включить сохранение лога заранее. После успешного входа почти всегда идёт навигация или редирект, и лог обнуляется ровно в интересный момент.
Третье: считают панель последней инстанцией. Запросы из Service Worker, из встроенного веб-представления мобильного приложения или из нативного слоя во вкладку не попадут, и без прокси или серверных логов картина неполная.