Chrome onAuthRequired: проверьте isProxy перед отправкой учётных данных
Обратный вызов аутентификации Chrome может описывать запрос прокси или запрос источника. Передача одних и тех же учётных данных обоим — ошибка области действия учётных данных.
Расширение браузера может столкнуться с запросами аутентификации из двух разных мест: прокси, передающего запрос, и целевого сайта. Они не должны автоматически получать одну и ту же учётную запись.
Полезный различитель в событии webRequest.onAuthRequired Chrome — это isProxy. Обратный вызов, который убирает эту проверку только ради исчезновения запроса, может начать передавать учётные данные прокси запросу источника.
Сопоставьте прокси, которому вы собираетесь доверять
Проверка isProxy — это начало. Также ограничьте обработку ожидаемым инициатором запроса прокси и контекстом запроса. Расширение, управляющее несколькими конечными точками, должно выбирать учётную запись, принадлежащую этой конечной точке, а не один глобальный пароль для каждого запроса.
Не предполагайте, что настройка маршрута прокси и обработка его входа — это одно разрешение или один вызов API. Chrome документирует их отдельно. Используйте текущую справку webRequest для данных событий и разрешений аутентификации. Пример регистрации слушателя Manifest V3 показывает синхронную регистрацию и выбор учётной записи внутри обратного вызова.
Проверьте поколение манифеста
Примеры, упоминающие экспериментальный API WebRequest, взяты из старых выпусков расширения. Текущие требования к разрешениям зависят от поколения манифеста расширения и модели развёртывания. В частности, обработка аутентификации имеет собственный поддерживаемый путь разрешений; устаревший пример блокирующего слушателя недостаточен, чтобы доказать, что расширение Manifest V3 может выполнять его без изменений.
Правильный обработчик должен также избегать бесконечного повторения одних и тех же отклонённых учётных данных. Второй запрос после предоставления учётной записи следует считать поводом для расследования, а не просьбой вечно повторять пароль.
Учётные данные должны оставаться в соответствующем защищённом пути обработки расширения. Не публикуйте их в файле PAC и не встраивайте в распространяемый пример. Цель — узко ограниченный вход через прокси, а не общебраузерное правило, отвечающее на каждый запрос аутентификации одним и тем же секретом.