Electron-Views können eigene HTTP-Proxy-Konten haben

Geben Sie in aktuellen Electron-Anwendungen jedem kontospezifischen WebContentsView eine eigene benannte Session. Nach der Bereitschaft der App kann ein asynchroner Helfer im Hauptprozess eine View konfigurieren:

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();
});

Verwenden Sie für jedes isolierte Konto einen eigenen partitionName und halten Sie die Listener-Variablen im Closure der jeweiligen View. Ein Name ohne persist: erzeugt eine Session im Arbeitsspeicher. Die Wiederverwendung derselben Partition nutzt bewusst deren Sessionzustand erneut.

Hängen Sie die View an das vorhandene Fenster und navigieren Sie erst, wenn Proxy und Handler bereit sind. Der Code richtet sich nach dem aktuellen login-Ereignisvertrag, einschließlich firstAuthAttempt, und bricht einen abgelehnten Wiederholungsversuch ab, statt dasselbe Konto endlos erneut zu senden.

Der Handler prüft, dass die Abfrage vom vorgesehenen Basic HTTP-Proxy stammt. Die Anmeldung einer Website ist für diese Zugangsdaten nicht zulässig.

Proxyregeln wählen den Endpunkt; login liefert das Konto. PAC-Dateien und manuelle Proxyregeln tragen das Passwort dieses Callbacks nicht selbst.

Dies ist HTTP-Proxy-Authentifizierung. Sie fügt Chromium keine SOCKS5-Authentifizierung hinzu. Bestehende Sessionverbindungen benötigen zudem ihre übliche Lebenszyklusbehandlung, wenn eine Route später geändert wird.