Chrome onAuthRequired: athugaðu isProxy áður en auðkenni eru send

Vafraviðbót getur mætt auðkenningarhausterum frá tveimur mismunandi stöðum: proxyinu sem ber beiðnina og áfangavefsíðunni. Þau mega ekki fá sama reikninginn sjálfkrafa.

Gagnlegi greinandinn í webRequest.onAuthRequired-atburði Chrome er isProxy. Callback sem fjarlægir þessa athugun bara til að láta skjáskot hverfa getur byrjað að veita proxy-auðkenni til upprunahausturs.

Passaðu við proxyið sem þú ætlar að treysta

Að athuga isProxy er byrjun. Takmarkaðu meðhöndlunina líka við væntan proxy-haustur og samhengi beiðninnar. Viðbót sem stýrir mörgum endapunktum ætti að velja reikninginn sem tilheyrir þeim endapunkti, ekki eitt alheimslykilorð fyrir hvert haustur.

Ekki gera ráð fyrir að stilling proxy-slóðar og meðhöndlun innskráningar hennar séu ein heimild eða eitt API-kall. Chrome skjalfestir þau aðskilin. Notaðu núverandi webRequest-tilvísun fyrir atburðagögn og auðkenningarheimildir. Dæmi um skráningu Manifest V3-hlustara sýnir samstillta skráningu og reikningsval inni í callbackinu.

Athugaðu kynslóð manifestssins

Dæmi sem nefna tilrauna-WebRequest-API koma frá gömlum viðbótarútgáfum. Núverandi heimildarkröfur ráðast af kynslóð manifestss viðbótarinnar og dreifingarlíkani. Einkum hefur auðkenningarmeðhöndlun sína eigin studdu heimildarslóð; úrelt dæmi um blokkerandi hlustara er ekki nóg til að staðfesta að Manifest V3-viðbót geti keyrt það óbreytt.

Réttur handler verður líka að forðast að endurtaka sömu höfnuðu auðkennin endalaust. Meðhöndlaðu annað haustur eftir að reikningur hefur verið veittur sem sönnunargagn til rannsóknar, ekki sem beiðni um að spila lykilorðið að eilífu.

Auðkenni eiga að vera í viðeigandi varðri meðhöndlunarslóð viðbótarinnar. Ekki birta þau í PAC-skrá og ekki harðkóða þau í dreifðu sýnishorni. Markmiðið er þröngt afmarkuð proxy-innskráning, ekki regla fyrir allan vafrann sem svarar hverju auðkenningarhaustri með sama leyndarmálinu.