Проблема в том, что когда эти учетные данные предоставлены, они, похоже, сохраняются / кэшируются где-то в расширении, к которому у разработчика нет доступа, и затем постоянно используются
Не совсем ... Прокси-серверы НЕ отправляют запросы аутентификации (требуется прокси-аутентификация 407) при каждом запросе соединения.Они часто проверяют это периодически (в зависимости от их настройки).
Браузер также может кэшироваться (например, в случае автоматического входа в Firefox, но в Chrome его нет).
Кто-нибудь знает, где сохраняются данные при возврате из прослушивателя webRequest.onAuthRequired, и есть ли способ очистить / очистить?
Важным моментом является то, что нет необходимостиклиент для отправки других учетных данных на тот же сервер, если предыдущий был верным.
учетные данные запроса к серверу:
- если переданы правильные, это разрешено, и сервер и браузероставьте это на некоторое время
- если пропущены неправильные данные, браузер не сохранит это, но сервер может заблокировать повторные попытки на некоторое время, а затем повторно запросить аутентификацию
Вы можете удалить& restart webRequest.onAuthRequired, но лично я не нашел реальной необходимости делать это для новых учетных данных, кроме случаев, когда я тестировал результаты плохой аутентификации во время разработки намеренноy отправка неверных учетных данных, что НЕ должно иметь место при использовании клиента
webRequest.onAuthRequired запускается всякий раз, когда сервер запрашивает это.Вы можете попробовать войти в систему, чтобы увидеть, как часто сервер это делает.
Код расширения (я имею в виду код разработчика, а не браузер) также может кэшировать учетные данные (чтобы избежать асинхронных вызовов и замедления аутентификации и, следовательно,связь).
Лично я кеширую все учетные данные для всех прокси и затем соответствующим образом отвечаю на запросы аутентификации.В противном случае вы можете изменить объект кэширования кода расширения и / или удалить и перезапустить webRequest.onAuthRequired.
Что на самом деле происходит, когда возвращается {cancel: true}, и почему все запросы к этому серверу затем продолжаютсяпотерпеть неудачу без запуска другого onAuthRequired?
Это зависит как от кода расширения, так и от настроек сервера.Настройки сервера могут блокировать соединения на некоторое время после неудачной аутентификации (чтобы предотвратить атаки Ddos).
Код расширения также может проверять правильность аутентификации перед отправкой {cancel: true}, которая уничтожает соединение.На практике отправка {cancel: true} требуется редко.
Существует также возможность попасть в цикл плохой аутентификации, что приведет к сбою соединения и может заблокировать браузер.
Inchrome, я бы использовал (действительно используйте и должен использовать) Promise, который является правильным способом аутентификации, поскольку код перестает выполняться, пока не будет выполнено обещание.Использование функции обратного вызова (которую использует Chrome API) не делает то, что может быть причиной вашей проблемы.
Для упрощения:
- add
webRequest.onAuthRequired - По запросу Auth, введите
new Promise, чтобы получить правильные учетные данные - Подготовьтесь к тому, чтобы избежать цикла плохой аутентификации