Chrome onAuthRequired: sjekk isProxy før påloggingsinformasjon sendes
Chroms autentiserings-callback kan beskrive en proxy- eller en opphavsutfordring. Å gi begge den samme påloggingsinformasjonen er en feil i omfanget.
En nettleserutvidelse kan møte autentiseringsutfordringer fra to forskjellige steder: proxyen som frakter forespørselen, og nettstedet du skal til. De må ikke automatisk få samme konto.
Den nyttige skilleren i Chroms webRequest.onAuthRequired-hendelse er isProxy. Et callback som fjerner denne kontrollen bare for å få en melding til å forsvinne, kan begynne å levere proxy-påloggingsinformasjon til en opphavsutfordring.
Samsvar med proxyen du vil stole på
Å sjekke isProxy er en start. Begrens også håndteringen til den forventede proxy-utfordreren og forespørselskonteksten. En utvidelse som administrerer flere endepunkter, bør velge kontoen som tilhører det endepunktet, ikke ett globalt passord for hver utfordring.
Ikke anta at oppsett av proxy-ruten og håndtering av innloggingen er én tillatelse eller ett API-kall. Chrome dokumenterer dem separat. Bruk gjeldende webRequest-referanse for hendelsesdata og autentiseringstillatelser. Et eksempel på registrering av en Manifest V3-lytter viser synkron registrering og kontovalg inne i callbacken.
Sjekk manifestgenerasjonen
Eksempler som nevner et eksperimentelt WebRequest-API, kommer fra gamle utvidelsesutgivelser. Gjeldende tillatelseskrav avhenger av utvidelsens manifestgenerasjon og distribusjonsmodell. Spesielt har autentiseringshåndtering sin egen støttede tillatelsesvei; et utdatert eksempel på en blokkerende lytter er ikke nok til å fastslå at en Manifest V3-utvidelse kan kjøre det uendret.
En korrekt behandler må også unngå å prøve de samme avviste påloggingsdataene på nytt i det uendelige. Behandle en ny utfordring etter en levert konto som bevis for å undersøke, ikke som en forespørsel om å spille av passordet for alltid.
Påloggingsinformasjon bør bli i utvidelsens passende beskyttede håndteringsvei. Ikke publiser dem i en PAC-fil, og ikke hardkod dem i et distribuert eksempel. Målet er en strengt avgrenset proxy-innlogging, ikke en nettleseromfattende regel som svarer på hver autentiseringsutfordring med samme hemmelighet.