Аутентификация через прокси Chrome: отсутствующие обратные вызовы onAuthRequired
Отделяйте видимость событий расширения от кэшированной аутентификации и завершённых запросов при отладке обратных вызовов входа через прокси Chrome.
Сообщение внутри onAuthRequired доказывает, что этот слушатель запускался. Пустая консоль не показывает, какой маршрут выбрал запрос и был ли он аутентифицирован ранее.
| Наблюдение | Держите отдельно от |
|---|---|
| Выбранный маршрут | Возник ли запрос аутентификации |
| Полученный запрос | Мог ли этот слушатель его наблюдать или обработать |
| Вывод слушателя | Смотрите ли вы в правильную консоль расширения |
| Итоговый результат запроса | Требовался ли новый обратный вызов |
Сначала установите фактический результат сети. Запрос может повторно использовать аутентификацию или уже установленное соединение, идти напрямую или вообще не достичь ожидаемой конечной точки.
Если возник актуальный запрос, проверьте фильтр, разрешения и поддерживаемый контекст расширения у слушателя. Поколение Manifest и модель развёртывания влияют на обработку аутентификации; устаревший пример блокирующего слушателя не может определять текущую модель разрешений. Наблюдайте консоль service worker расширения, когда слушатель работает именно там, вместо того чтобы полагаться на вывод страницы. Для Manifest V3 зарегистрируйте слушатель аутентификации синхронно до асинхронной загрузки учётной записи.
Повторная навигация не обязательно означает новый запрос. Исторические отчёты о кэше не устанавливают правило, что событие срабатывает ровно один раз за сеанс браузера; наблюдайте за используемым браузером и версией.
Для контролируемого сравнения изолируйте нужную конфигурацию расширения и учётную запись с помощью поддерживаемых инструментов браузера. Избегайте недокументированных приёмов очистки кэша или изменения всей операционной системы. Четыре наблюдения определяют, отсутствует ли слушатель или этому соединению он просто не был нужен.