Brauserilaiendus võib kohata autentimise väljakutseid kahest erinevast kohast: päringut edastav puhverserver ja sihtveebisait. Need ei tohi automaatselt sama kontot saada.

Kasulik eristaja Chrome'i sündmuses webRequest.onAuthRequired on isProxy. Tagasikutse, mis eemaldab selle kontrolli ainult selleks, et viip kaoks, võib hakata puhverserveri mandaate päritolu väljakutsele esitama.

Sobita puhverserver, mida kavatsed usaldada

isProxy kontrollimine on algus. Piira töötlemist ka oodatud puhverserveri esitaja ja päringu kontekstiga. Mitut lõpp-punkti haldav laiendus peaks valima sellele lõpp-punktile kuuluva konto, mitte ühe ülemaailmse parooli iga väljakutse jaoks.

Ära eelda, et puhverserveri marsruudi seadistamine ja selle sisselogimise töötlemine on üks luba või üks API-kutse. Chrome dokumenteerib need eraldi. Kasuta sündmuste andmete ja autentimislubade jaoks praegust webRequesti viidet. Manifest V3 kuulaja registreerimise näide näitab sünkroonset registreerimist ja konto valimist tagasikutse sees.

Kontrolli manifesti põlvkonda

Eksperimentaalset WebRequesti API-t mainivad näited pärinevad vanadest laiendusväljaannetest. Praegused loa nõuded sõltuvad laienduse manifesti põlvkonnast ja juurutamise mudelist. Eelkõige on autentimise töötlemisel oma toetatud loa tee; aegunud blokeeriva kuulaja näide ei ole piisav, et tõestada, et Manifest V3 laiendus saab seda muutmata käitada.

Korrektne töötleja peab vältima ka samade tagasilükatud mandaatide lõputut uuesti proovimist. Käsitle teist väljakutset pärast antud kontot uurimist vajava tõendina, mitte palvena parooli igavesti uuesti esitada.

Mandaadid peaksid jääma laienduse sobivasse kaitstud töötlemisteele. Ära avalda neid PAC-failis ega kõvakodeeri levitatavasse näidissse. Eesmärk on kitsalt piiritletud puhverserveri sisselogimine, mitte kogu brauseri reegel, mis vastab igale autentimise väljakutsele sama saladusega.

Seotud artiklid