Chrome onAuthRequired: controlla isProxy prima di inviare le credenziali

Un'estensione del browser può incontrare sfide di autenticazione da due luoghi diversi: il proxy che trasporta la richiesta e il sito web di destinazione. Non devono ricevere automaticamente lo stesso account.

Il discriminante utile nell'evento webRequest.onAuthRequired di Chrome è isProxy. Un callback che rimuove questo controllo solo per far sparire un prompt può iniziare a fornire le credenziali del proxy a una sfida dell'origine.

Abbina il proxy di cui intendi fidarti

Controllare isProxy è un inizio. Limita anche la gestione allo sfidante proxy previsto e al contesto della richiesta. Un'estensione che gestisce più endpoint dovrebbe selezionare l'account appartenente a quell'endpoint, non un'unica password globale per ogni sfida.

Non dare per scontato che impostare la rotta del proxy e gestirne l'accesso siano un'unica autorizzazione o un'unica chiamata API. Chrome li documenta separatamente. Usa il riferimento webRequest attuale per i dati degli eventi e le autorizzazioni di autenticazione. Un esempio di registrazione di un listener Manifest V3 mostra la registrazione sincrona e la selezione dell'account all'interno del callback.

Controlla la generazione del manifest

Gli esempi che citano un'API WebRequest sperimentale provengono da vecchie versioni dell'estensione. I requisiti attuali di autorizzazione dipendono dalla generazione del manifest dell'estensione e dal modello di distribuzione. In particolare, la gestione dell'autenticazione ha un proprio percorso di autorizzazione supportato; un esempio obsoleto di listener bloccante non basta a stabilire che un'estensione Manifest V3 possa eseguirlo senza modifiche.

Un gestore corretto deve anche evitare di ritentare all'infinito le stesse credenziali rifiutate. Tratta una seconda sfida dopo un account fornito come prova da investigare, non come richiesta di riprodurre la password per sempre.

Le credenziali dovrebbero restare nel percorso di gestione protetto appropriato dell'estensione. Non pubblicarle in un file PAC e non codificarle direttamente in un esempio distribuito. L'obiettivo è un accesso proxy con ambito ristretto, non una regola per tutto il browser che risponde a ogni sfida di autenticazione con lo stesso segreto.