Chrome onAuthRequired: kontroller isProxy, før legitimationsoplysninger sendes
Chromens godkendelses-callback kan beskrive en proxy-udfordring eller en oprindelsesudfordring. At give begge de samme legitimationsoplysninger er en fejl i oplysningernes omfang.
En browserudvidelse kan møde godkendelsesudfordringer fra to forskellige steder: proxyserveren, der bærer anmodningen, og destinationswebstedet. De må ikke automatisk modtage den samme konto.
Den nyttige skelnen i Chromens webRequest.onAuthRequired-begivenhed er isProxy. Et callback, der fjerner denne kontrol blot for at få en prompt til at forsvinde, kan begynde at levere proxy-legitimationsoplysninger til en oprindelsesudfordring.
Match den proxy, du har til hensigt at stole på
At kontrollere isProxy er en begyndelse. Begræns også håndteringen til den forventede proxy-udfordrer og anmodningskonteksten. En udvidelse, der administrerer flere endepunkter, bør vælge den konto, der hører til det endepunkt, ikke én global adgangskode til hver udfordring.
Antag ikke, at opsætning af proxy-ruten og håndtering af dens login er én tilladelse eller ét API-kald. Chrome dokumenterer dem hver for sig. Brug den aktuelle webRequest-reference til begivenhedsdata og godkendelsestilladelser. Et eksempel på registrering af en Manifest V3-lytter viser synkron registrering og kontoval inden i callbacket.
Kontroller manifestgenerationen
Eksempler, der nævner en eksperimentel WebRequest-API, stammer fra gamle udvidelsesudgivelser. De aktuelle tilladelseskrav afhænger af udvidelsens manifestgeneration og udrulningsmodel. Især har godkendelseshåndtering sin egen understøttede tilladelsesvej; et forældet blokerende lyttereksempel er ikke nok til at fastslå, at en Manifest V3-udvidelse kan køre det uændret.
En korrekt handler skal også undgå at gentage de samme afviste legitimationsoplysninger i det uendelige. Behandl en anden udfordring efter en leveret konto som bevis for at undersøge sagen, ikke som en anmodning om at afspille adgangskoden for evigt.
Legitimationsoplysninger bør blive i udvidelsens passende beskyttede håndteringsvej. Offentliggør dem ikke i en PAC-fil, og hardcod dem ikke i et distribueret eksempel. Målet er et snævert afgrænset proxy-login, ikke en browserdækkende regel, der besvarer hver godkendelsesudfordring med den samme hemmelighed.