Chrome onAuthRequired: před odesláním přihlašovacích údajů zkontrolujte isProxy

Rozšíření prohlížeče se může setkat s výzvami k ověření ze dvou různých míst: proxy přenášející požadavek a cílový web. Nesmějí automaticky dostat stejný účet.

Užitečným rozlišovačem v události webRequest.onAuthRequired Chromu je isProxy. Zpětné volání, které toto ověření odstraní jen proto, aby zmizela výzva, může začít dodávat přihlašovací údaje proxy výzvě původu.

Sladěte proxy, které hodláte důvěřovat

Kontrola isProxy je začátek. Omezte také zpracování na očekávaného vyzývatele proxy a kontext požadavku. Rozšíření spravující několik koncových bodů by mělo vybrat účet náležející danému koncovému bodu, ne jedno globální heslo pro každou výzvu.

Nepředpokládejte, že nastavení trasy proxy a zpracování jejího přihlášení jsou jedno oprávnění nebo jedno volání API. Chrome je dokumentuje odděleně. Pro data událostí a oprávnění k ověřování použijte aktuální referenci webRequest. Příklad registrace posluchače Manifest V3 ukazuje synchronní registraci a výběr účtu uvnitř zpětného volání.

Zkontrolujte generaci manifestu

Příklady zmiňující experimentální API WebRequest pocházejí ze starých vydání rozšíření. Současné požadavky na oprávnění závisí na generaci manifestu rozšíření a modelu nasazení. Zejména zpracování ověřování má vlastní podporovanou cestu oprávnění; zastaralý příklad blokujícího posluchače nestačí k prokázání, že rozšíření Manifest V3 jej může spustit beze změny.

Správný obslužný kód se musí také vyhnout nekonečnému opakování stejných odmítnutých údajů. Druhou výzvu po dodaném účtu berte jako důkaz k prošetření, nikoli jako požadavek znovu přehrávat heslo navěky.

Přihlašovací údaje by měly zůstat ve vhodné chráněné cestě zpracování rozšíření. Nezveřejňujte je v souboru PAC ani je nezapisujte natvrdo do distribuované ukázky. Cílem je úzce vymezené přihlášení proxy, ne pravidlo pro celý prohlížeč, které na každou ověřovací výzvu odpovídá stejným tajemstvím.