Widoki Electron mogą mieć osobne konta proxy HTTP

W obecnych aplikacjach Electron każdemu powiązanemu z kontem WebContentsView nadaj własną nazwaną sesję. Gdy aplikacja jest gotowa, asynchroniczny pomocnik w procesie głównym może skonfigurować jeden widok:

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

Podaj odrębny partitionName dla każdego izolowanego konta i trzymaj zmienne nasłuchujące w domknięciu tego widoku. Nazwa bez persist: tworzy sesję w pamięci. Ponowne użycie tej samej partycji celowo ponownie używa jej stanu sesji.

Podłącz widok do istniejącego okna i nawiguj dopiero po przygotowaniu jego proxy i programu obsługi. Kod odpowiada bieżącej umowie zdarzenia login, w tym firstAuthAttempt, i anuluje odrzuconą ponowną próbę zamiast bez końca wysyłać to samo konto.

Program obsługi sprawdza, czy wyzwanie pochodzi z zamierzonego Basic HTTP proxy. Logowanie do witryny nie kwalifikuje się do tych danych.

Reguły proxy wybierają punkt końcowy; login dostarcza konto. Pliki PAC i ręczne reguły proxy same nie przenoszą hasła tego callbacku.

To uwierzytelnianie proxy HTTP. Nie dodaje uwierzytelniania SOCKS5 do Chromium. Istniejące połączenia sesji również wymagają zwykłego zarządzania cyklem życia, gdy trasa zostanie później zmieniona.