Chrome onAuthRequired: a hitelesítő adatok küldése előtt ellenőrizze az isProxy értékét
A Chrome hitelesítési visszahívása proxy- vagy eredeti kihívást írhat le. Ha mindkettő ugyanazokat a hitelesítő adatokat kapja, az a hitelesítő adatok hatókörének hibája.
Egy böngészőbővítmény két különböző helyről kaphat hitelesítési kihívást: a kérést továbbító proxytól és a célwebhelytől. Nem kaphatják automatikusan ugyanazt a fiókot.
A hasznos megkülönböztető a Chrome webRequest.onAuthRequired eseményében az isProxy. Az a visszahívás, amely csak azért távolítja el ezt az ellenőrzést, hogy eltűnjön egy kérés, elkezdheti a proxy hitelesítő adatait egy eredeti kihívásnak átadni.
Ahhoz a proxyhoz igazodjon, amelyben meg akar bízni
Az isProxy ellenőrzése csak a kezdet. Korlátozza a kezelést a várt proxy-kihívóra és a kérés kontextusára is. A több végpontot kezelő bővítménynek az adott végponthoz tartozó fiókot kell kiválasztania, nem egyetlen globális jelszót minden kihíváshoz.
Ne feltételezze, hogy a proxy útvonalának beállítása és bejelentkezésének kezelése egyetlen engedély vagy egyetlen API-hívás. A Chrome külön dokumentálja őket. Az eseményadatokhoz és a hitelesítési engedélyekhez a jelenlegi webRequest-referenciát használja. A Manifest V3-figyelő regisztrációjának példája szinkron regisztrációt és fiókválasztást mutat a visszahíváson belül.
Ellenőrizze a manifeszt generációját
A kísérleti WebRequest API-t említő példák régi bővítménykiadásokból származnak. A jelenlegi engedélykövetelmények a bővítmény manifesztgenerációjától és telepítési modelljétől függenek. Különösen a hitelesítés kezelésének saját támogatott engedélyútvonala van; egy elavult blokkoló figyelő példa nem elég annak megállapításához, hogy egy Manifest V3-bővítmény változtatás nélkül futtathatja.
A helyes kezelőnek azt is el kell kerülnie, hogy ugyanazokat az elutasított hitelesítő adatokat végtelenül újra próbálja. A fiók átadása utáni második kihívást kivizsgálandó bizonyítékként kezelje, ne a jelszó örökös újrajátszására vonatkozó kérésként.
A hitelesítő adatoknak a bővítmény megfelelő védett kezelési útvonalán kell maradniuk. Ne tegye közzé őket PAC-fájlban, és ne kódolja be őket egy terjesztett példába. A cél egy szűk hatókörű proxy-bejelentkezés, nem egy böngészőszintű szabály, amely minden hitelesítési kihívásra ugyanazzal a titokkal válaszol.