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