Retumila etendaĵo povas renkonti aŭtentigajn defiojn el du malsamaj lokoj: la prokurilo, kiu transportas la peton, kaj la celloka retejo. Ili ne rajtas aŭtomate ricevi la saman konton.

La utila distingilo en la okazaĵo webRequest.onAuthRequired de Chrome estas isProxy. Retrovoko, kiu forigas tiun kontrolon nur por ke invito malaperu, povas ekdoni akreditaĵojn de la prokurilo al defio de origino.

Kongruigu la prokurilon, kiun vi intencas fidi

Kontroli isProxy estas komenco. Ankaŭ limigu la pritraktadon al la atendata prokurila defiinto kaj la petkunteksto. Etendaĵo, kiu administras plurajn finpunktojn, devus elekti la konton apartenantan al tiu finpunkto, ne unu tutmondan pasvorton por ĉiu defio.

Ne supozu, ke starigi la prokurilan vojon kaj trakti ĝian saluton estas unu permeso aŭ unu API-alvoko. Chrome dokumentas ilin aparte. Uzu la aktualan referencon de webRequest por okazaĵaj datumoj kaj aŭtentigaj permesoj. Ekzemplo de registrado de Manifest V3 aŭskultanto montras sinkronan registradon kaj kontoelektadon ene de la retrovoko.

Kontrolu la manifestan generacion

Ekzemploj menciantaj eksperimentan WebRequest-API devenas de malnovaj eldonoj de etendaĵoj. Aktualaj permespostuloj dependas de la manifesta generacio de la etendaĵo kaj de ĝia disfaldmodelo. Precipe, aŭtentiga pritraktado havas sian propran subtenatan permesvojon; malnova ekzemplo de blokanta aŭskultanto ne sufiĉas por pruvi, ke Manifest V3-etendaĵo povas plenumi ĝin senŝanĝe.

Ĝusta traktilo ankaŭ devas eviti senfinan rean provon de la samaj rifuzitaj akreditaĵoj. Traktu duan defion post donita konto kiel indicon por esplori, ne kiel peton por eterne reludi la pasvorton.

Akreditaĵoj restu en la taŭga protektita traktvojo de la etendaĵo. Ne publikigu ilin en PAC-dosiero kaj ne enkodigu ilin en distribuita specimeno. La celo estas mallarĝe limigita prokurila saluto, ne tutretumila regulo, kiu respondas ĉiun aŭtentigan defion per la sama sekreto.

Rilataj artikoloj