Chrome onAuthRequired: проверите isProxy пре слања акредитива

Проширење прегледача може наићи на изазове аутентификације са два различита места: проксија који преноси захтев и одредишне веб странице. Она не смеју аутоматски добити исти рачун.

Користан разликовни знак у Chrome догађају webRequest.onAuthRequired јесте isProxy. Повратни позив који уклони ту проверу само да би нестао упит може почети да доставља акредитиве проксија изазову извора.

Ускладите прокси коме намеравате да верујете

Провера isProxy је почетак. Такође ограничите обраду на очекиваног изазивача проксија и контекст захтева. Проширење које управља са неколико крајњих тачака треба да одабере рачун који припада тој крајњој тачки, а не једну глобалну лозинку за сваки изазов.

Не претпостављајте да су постављање прокси руте и обрада њене пријаве једно дозвола или један API позив. Chrome их документује одвојено. Користите тренутну референцу webRequest за податке о догађајима и дозволе за аутентификацију. Пример регистрације слушаоца Manifest V3 приказује синхрону регистрацију и избор рачуна унутар повратног позива.

Проверите генерацију манифеста

Примери који спомињу експериментални WebRequest API долазе из старих издања проширења. Тренутни захтеви за дозволама зависе од генерације манифеста проширења и модела имплементације. Посебно, обрада аутентификације има сопствени подржани пут дозвола; застарео пример блокирајућег слушаоца није довољан да се утврди да проширење Manifest V3 може то изводити непромењено.

Исправан руковалац такође мора избегавати бесконачно поновно покушавање истих одбијених акредитива. Други изазов након достављеног рачуна третирајте као доказ за истрагу, а не као захтев да се лозинка заувек изнова репродукује.

Акредитиви би требало да остану на одговарајућем заштићеном путу обраде проширења. Не објављујте их у PAC датотеци и не уграђујте их у дистрибуирани пример. Циљ је уско ограничена прокси пријава, а не правило на нивоу прегледача које сваком изазову аутентификације одговара истим тајном.