Chrome onAuthRequired: isProxy prüfen, bevor Anmeldedaten gesendet werden
Chromes Authentifizierungs-Callback kann eine Proxy- oder eine Origin-Herausforderung beschreiben. Beiden dieselben Anmeldedaten zu geben, ist ein Fehler im Geltungsbereich der Anmeldedaten.
Eine Browsererweiterung kann auf Authentifizierungsherausforderungen von zwei verschiedenen Stellen treffen: dem Proxy, der die Anfrage weiterleitet, und der Zielwebsite. Beide dürfen nicht automatisch dasselbe Konto erhalten.
Der nützliche Unterscheider im Chrome-Ereignis webRequest.onAuthRequired ist isProxy. Ein Callback, der diese Prüfung nur entfernt, damit eine Eingabeaufforderung verschwindet, kann damit beginnen, Proxy-Anmeldedaten an eine Origin-Herausforderung zu liefern.
Den Proxy abgleichen, dem Sie vertrauen wollen
Die Prüfung von isProxy ist ein Anfang. Beschränken Sie die Behandlung außerdem auf den erwarteten Proxy-Herausforderer und den Anfragekontext. Eine Erweiterung, die mehrere Endpunkte verwaltet, sollte das zu diesem Endpunkt gehörende Konto wählen, nicht ein einziges globales Passwort für jede Herausforderung.
Gehen Sie nicht davon aus, dass das Einrichten der Proxy-Route und die Behandlung ihres Logins eine Berechtigung oder ein API-Aufruf sind. Chrome dokumentiert sie getrennt. Verwenden Sie die aktuelle webRequest-Referenz für Ereignisdaten und Authentifizierungsberechtigungen. Ein Beispiel für die Registrierung eines Manifest-V3-Listeners zeigt die synchrone Registrierung und Kontowahl innerhalb des Callbacks.
Die Manifest-Generation prüfen
Beispiele, die eine experimentelle WebRequest-API erwähnen, stammen aus alten Erweiterungsversionen. Aktuelle Berechtigungsanforderungen hängen von der Manifest-Generation und dem Bereitstellungsmodell der Erweiterung ab. Insbesondere hat die Authentifizierungsbehandlung ihren eigenen unterstützten Berechtigungspfad; ein veraltetes Beispiel eines blockierenden Listeners reicht nicht aus, um zu belegen, dass eine Manifest-V3-Erweiterung ihn unverändert ausführen kann.
Ein korrekter Handler muss außerdem vermeiden, dieselben abgelehnten Anmeldedaten endlos erneut zu versuchen. Behandeln Sie eine zweite Herausforderung nach einem gelieferten Konto als Anlass zur Untersuchung und nicht als Aufforderung, das Passwort ewig erneut abzuspielen.
Anmeldedaten sollten im geeigneten geschützten Behandlungspfad der Erweiterung bleiben. Veröffentlichen Sie sie nicht in einer PAC-Datei und kodieren Sie sie nicht fest in ein verteiltes Beispiel. Das Ziel ist ein eng begrenzter Proxy-Login, keine browsweite Regel, die jede Authentifizierungsherausforderung mit demselben Geheimnis beantwortet.