Proširenje preglednika može naići na izazove autentifikacije s dva različita mjesta: proxyja koji prenosi zahtjev i odredišnog web-mjesta. Ne smiju automatski dobiti isti račun.

Koristan razlikovni znak u Chromeovu događaju webRequest.onAuthRequired jest isProxy. Povratni poziv koji ukloni tu provjeru samo da bi upit nestao može početi dostavljati akreditive proxyja izazovu izvora.

Uskladite proxy kojemu namjeravate vjerovati

Provjera isProxy je početak. Ograničite i obradu na očekivanog izazivača proxyja i kontekst zahtjeva. Proširenje koje upravlja s nekoliko krajnjih točaka treba odabrati račun koji pripada toj krajnjoj točki, a ne jednu globalnu zaporku za svaki izazov.

Ne pretpostavljajte da su postavljanje proxy rute i obrada njezine prijave jedno dopuštenje ili jedan poziv API-ja. Chrome ih dokumentira odvojeno. Koristite trenutačnu referencu webRequest za podatke o događajima i dopuštenja za autentifikaciju. Primjer registracije slušatelja Manifest V3 prikazuje sinkronu registraciju i odabir računa unutar povratnog poziva.

Provjerite generaciju manifesta

Primjeri koji spominju eksperimentalni WebRequest API dolaze iz starih izdanja proširenja. Trenutačni zahtjevi za dopuštenjima ovise o generaciji manifesta proširenja i modelu implementacije. Posebno, obrada autentifikacije ima vlastiti podržani put dopuštenja; zastario primjer blokirajućeg slušatelja nije dovoljan da se utvrdi da proširenje Manifest V3 može to izvoditi nepromijenjeno.

Ispravan rukovatelj također mora izbjegavati beskonačno ponovno pokušavanje istih odbijenih akreditiva. Drugi izazov nakon dostavljenog računa tretirajte kao dokaz za istragu, a ne kao zahtjev da se zaporka zauvijek iznova reproducira.

Akreditivi bi trebali ostati na odgovarajućem zaštićenom putu obrade proširenja. Ne objavljujte ih u PAC datoteci i ne ugrađujte ih u distribuirani primjer. Cilj je usko ograničena proxy prijava, a ne pravilo na razini preglednika koje svakom izazovu autentifikacije odgovara istom tajnom.

Povezani članci