Electron-views kunnen aparte HTTP-proxyaccounts hebben

Geef in huidige Electron-apps elke accountspecifieke WebContentsView zijn eigen benoemde sessie. Zodra de app gereed is, kan een asynchrone helper in het hoofdproces één view configureren:

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

Geef elke geïsoleerde account een aparte partitionName en houd de listenervariabelen in de closure van die view. Een naam zonder persist: maakt een sessie in het geheugen. Hergebruik van dezelfde partitie hergebruikt bewust de sessiestatus ervan.

Koppel de view aan het bestaande venster en navigeer pas wanneer de proxy en de handler gereed zijn. De code volgt het huidige login-eventcontract, inclusief firstAuthAttempt, en annuleert een geweigerde herhaalde poging in plaats van hetzelfde account eindeloos opnieuw te versturen.

De handler controleert of de uitdaging van de bedoelde Basic HTTP-proxy komt. De login van een website is niet geldig voor deze inloggegevens.

Proxyregels kiezen het eindpunt; login levert het account. PAC-bestanden en handmatige proxyregels dragen het wachtwoord van deze callback niet zelf.

Dit is HTTP-proxyauthenticatie. Het voegt geen SOCKS5-authenticatie toe aan Chromium. Bestaande sessieverbindingen hebben ook hun gebruikelijke levenscyclusbeheer nodig wanneer een route later wordt gewijzigd.