Razširitev brskalnika lahko naleti na izzive preverjanja pristnosti z dveh različnih mest: proxyja, ki prenaša zahtevo, in ciljnega spletnega mesta. Ne smeta samodejno prejeti istega računa.

Koristna razlikovalna lastnost v dogodku webRequest.onAuthRequired Chroma je isProxy. Povratni klic, ki odpravi to preverjanje samo zato, da bi izginilo pozivno okno, lahko začne pošiljati poverilnice proxyja izzivu izvora.

Ujemite se s proxyjem, ki mu nameravate zaupati

Preverjanje isProxy je začetek. Omejite tudi obdelavo na pričakovanega izzivalca proxyja in kontekst zahteve. Razširitev, ki upravlja več končnih točk, mora izbrati račun, ki pripada tej končni točki, ne enega globalnega gesla za vsak izziv.

Ne predpostavljajte, da sta nastavljanje poti proxyja in obdelava njegove prijave eno dovoljenje ali en klic API. Chrome ju dokumentira ločeno. Za podatke o dogodkih in dovoljenja za preverjanje pristnosti uporabite trenutni referenčni dokument webRequest. Primer registracije poslušalca Manifest V3 prikazuje sinhrono registracijo in izbiro računa znotraj povratnega klica.

Preverite generacijo manifesta

Primeri, ki omenjajo eksperimentalni API WebRequest, izhajajo iz starih izdaj razširitve. Trenutne zahteve glede dovoljenj so odvisne od generacije manifesta razširitve in modela uvajanja. Predvsem ima obdelava preverjanja pristnosti svojo podprto pot dovoljenj; zastarel primer blokirnega poslušalca ne zadošča za dokaz, da lahko razširitev Manifest V3 to izvaja nespremenjeno.

Pravilen upravljalnik se mora izogniti tudi neskončnemu ponavljanju istih zavrnjenih poverilnic. Drugi izziv po zagotovljenem računu obravnavajte kot dokaz za preiskavo, ne kot zahtevo po večnem ponovnem predvajanju gesla.

Poverilnice naj ostanejo na ustrezni zaščiteni poti obdelave razširitve. Ne objavljajte jih v datoteki PAC in jih ne vgrajujte v razširjeni primer. Cilj je ozko omejena prijava proxyja, ne pravilo za celoten brskalnik, ki na vsak izziv preverjanja pristnosti odgovori z isto skrivnostjo.

Sorodni članki