Rozšírenie prehliadača sa môže stretnúť s výzvami na overenie z dvoch rôznych miest: proxy prenášajúceho požiadavku a cieľového webu. Nesmú automaticky dostať ten istý účet.

Užitočným rozlišovačom v udalosti webRequest.onAuthRequired Chrome je isProxy. Spätné volanie, ktoré toto overenie odstráni len preto, aby zmizla výzva, môže začať dodávať prihlasovacie údaje proxy výzve pôvodu.

Zlaďte proxy, ktorému hodláte dôverovať

Kontrola isProxy je začiatok. Obmedzte tiež spracovanie na očakávaného vyzývateľa proxy a kontext požiadavky. Rozšírenie spravujúce niekoľko koncových bodov by malo vybrať účet patriaci danému koncovému bodu, nie jedno globálne heslo pre každú výzvu.

Nepredpokladajte, že nastavenie trasy proxy a spracovanie jej prihlásenia sú jedno povolenie alebo jedno volanie API. Chrome ich dokumentuje oddelene. Pre údaje udalostí a povolenia na overenie použite aktuálnu referenciu webRequest. Príklad registrácie poslucháča Manifest V3 ukazuje synchrónnu registráciu a výber účtu vnútri spätného volania.

Skontrolujte generáciu manifestu

Príklady spomínajúce experimentálne API WebRequest pochádzajú zo starých vydaní rozšírenia. Súčasné požiadavky na povolenia závisia od generácie manifestu rozšírenia a modelu nasadenia. Najmä spracovanie overenia má vlastnú podporovanú cestu povolení; zastaraný príklad blokujúceho poslucháča nestačí na preukázanie, že rozšírenie Manifest V3 ho môže spustiť bez zmeny.

Správny obslužný kód sa musí tiež vyhnúť nekonečnému opakovaniu tých istých odmietnutých údajov. Druhú výzvu po dodanom účte berte ako dôkaz na vyšetrenie, nie ako požiadavku znova prehrávať heslo navždy.

Prihlasovacie údaje by mali zostať v príslušnej chránenej ceste spracovania rozšírenia. Nezverejňujte ich v súbore PAC a nezakódujte ich natvrdo do distribuovanej ukážky. Cieľom je úzko vymedzené prihlásenie proxy, nie pravidlo pre celý prehliadač, ktoré odpovedá na každú overovaciu výzvu rovnakým tajomstvom.

Súvisiace články