Chrome onAuthRequired: sjekk isProxy før legitimasjon blir send

Ei nettlesarutviding kan møte autentiseringsutfordringar frå to ulike stader: proxyen som fraktar førespurnaden, og nettstaden ein skal til. Dei må ikkje automatisk få same konto.

Den nyttige skilleren i webRequest.onAuthRequired-hendinga til Chrome er isProxy. Ein callback som fjernar denne kontrollen berre for å få ei melding til å forsvinne, kan byrje å levere proxy-legitimasjon til ei opphavsutfordring.

Samsvar med proxyen du vil stole på

Å sjekke isProxy er ein start. Avgrens òg handteringa til den venta proxy-utfordraren og førespurnadskonteksten. Ei utviding som styrer fleire endepunkt, bør velje kontoen som høyrer til det endepunktet, ikkje eitt globalt passord for kvar utfordring.

Ikkje gå ut frå at oppsett av proxy-ruta og handtering av innlogginga er éi løyve eller eitt API-kall. Chrome dokumenterer dei kvar for seg. Bruk gjeldande webRequest-referanse for hendingsdata og autentiseringsløyve. Eit døme på registrering av ein Manifest V3-lyttar viser synkron registrering og kontoval inne i callbacken.

Sjekk manifestgenerasjonen

Døme som nemner eit eksperimentelt WebRequest-API, kjem frå gamle utvidingsutgåver. Gjeldande løyvekrav avheng av manifestgenerasjonen til utvidinga og distribusjonsmodellen. Særleg har autentiseringshandtering sin eigen støtta løyveveg; eit utdatert døme på ein blokkerande lyttar er ikkje nok til å fastslå at ei Manifest V3-utviding kan køyre det uendra.

Ein korrekt handterar må òg unngå å prøve den same avviste legitimasjonen på nytt i det uendelege. Handsame ei ny utfordring etter ein levert konto som prov for å undersøkje, ikkje som ein førespurnad om å spele av passordet for alltid.

Legitimasjon bør bli i den høvelege verna handteringsvegen til utvidinga. Ikkje publiser dei i ei PAC-fil, og ikkje hardkod dei i eit distribuert døme. Målet er ei strengt avgrensa proxy-innlogging, ikkje ei nettlesaromfattande regel som svarar på kvar autentiseringsutfordring med same løyndom.