Chrome-proxyverificatie: ontbrekende onAuthRequired-callbacks
Scheid de zichtbaarheid van extensiegebeurtenissen van gecachte verificatie en voltooide verzoeken wanneer je login-callbacks van de Chrome-proxy debugt.
Een bericht binnen onAuthRequired bewijst dat die listener liep. Een lege console toont niet welke route het verzoek nam of dat een eerdere uitwisseling verificatie leverde.
| Observatie | Houd dit gescheiden van |
|---|---|
| Gekozen route | Of er een verificatie-uitdaging optrad |
| Ontvangen uitdaging | Of deze listener die kon waarnemen of afhandelen |
| Uitvoer van de listener | Of je naar de juiste extensieconsole kijkt |
| Eindresultaat van het verzoek | Of een nieuwe callback nodig was |
Stel eerst de werkelijke netwerkuitkomst vast. Het verzoek kan verificatie of een bestaande verbinding hergebruiken, rechtstreeks gaan, of nooit het verwachte eindpunt bereiken.
Als er een relevante uitdaging optrad, onderzoek dan het filter, de machtigingen en de ondersteunde extensiecontext van de listener. Manifest-generatie en implementatiemodel beïnvloeden de verificatieafhandeling; een verouderd voorbeeld met een blokkerende listener kan het huidige machtigingsmodel niet definiëren. Bekijk de console van de service worker van de extensie wanneer de listener daar draait, in plaats van op pagina-uitvoer te vertrouwen. Voor Manifest V3, registreer de verificatielistener synchroon vóór het asynchroon laden van het account.
Herhaalde navigatie is niet noodzakelijk een nieuwe uitdaging. Historische cache-rapporten stellen geen regel vast dat de gebeurtenis precies één keer per browsersessie optreedt; observeer de browser en versie die worden gebruikt.
Isoleer voor een gecontroleerde vergelijking de bedoelde extensieconfiguratie en het account met ondersteunde browsergereedschappen. Vermijd ongedocumenteerde trucs om de cache te legen of het hele besturingssysteem te wijzigen. De vier observaties bepalen of een listener ontbreekt of dat deze verbinding hem simpelweg niet nodig had.