Nelle applicazioni Electron attuali, assegnate a ogni WebContentsView associata a un account la propria sessione denominata. Quando l'applicazione è pronta, un helper asincrono nel processo principale può configurare una vista:

const routeSession = session.fromPartition(partitionName);
await routeSession.setProxy({
  mode: 'fixed_servers',
  proxyRules: `http://${proxyHost}:${proxyPort}`,
});
const view = new WebContentsView({
  webPreferences: { session: routeSession },
});
view.webContents.on('login', (event, details, authInfo, callback) => {
  if (!authInfo.isProxy
      || authInfo.scheme.toLowerCase() !== 'basic'
      || authInfo.host !== proxyHost
      || authInfo.port !== proxyPort) return;
  event.preventDefault();
  if (details.firstAuthAttempt) callback(proxyUser, proxyPassword);
  else callback();
});

Fornite un partitionName distinto per ogni account isolato e mantenete le variabili del listener nella closure di quella vista. Un nome senza persist: crea una sessione in memoria. Riusare la stessa partizione riusa deliberatamente il suo stato di sessione.

Collegate la vista alla finestra esistente e navigate solo quando il suo proxy e il suo gestore sono pronti. Il codice mira al contratto attuale dell'evento login, incluso firstAuthAttempt, e annulla un tentativo ripetuto rifiutato invece di reinviare lo stesso account all'infinito.

Il gestore verifica che la sfida provenga dal proxy Basic HTTP previsto. L'accesso a un sito web non è idoneo per queste credenziali.

Le regole proxy scelgono l'endpoint; login fornisce l'account. I file PAC e le regole proxy manuali non portano di per sé la password di questo callback.

Questa è autenticazione proxy HTTP. Non aggiunge l'autenticazione SOCKS5 a Chromium. Anche le connessioni di sessione esistenti necessitano della loro normale gestione del ciclo di vita quando una rotta viene modificata in seguito.

Articoli correlati