Electron Views Can Have Separate HTTP Proxy Accounts

For current Electron applications, give each account-specific WebContentsView its own named session. After app readiness, an async main-process helper can configure one view:

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

Supply a distinct partitionName for each isolated account and keep the listener variables in that view's own closure. A name without persist: creates an in-memory session. Reusing the same partition intentionally reuses its session state.

Attach the view to the existing window and navigate only after its proxy and handler are ready. The code targets the current login event contract, including firstAuthAttempt, and cancels a rejected repeated attempt instead of resubmitting the same account indefinitely.

The handler checks that the challenge is from the intended Basic HTTP proxy. A website's login is not eligible for those credentials.

Proxy rules select the endpoint; login supplies the account. PAC files and manual proxy rules do not themselves carry this callback's password.

This is HTTP proxy authentication. It does not add SOCKS5 authentication to Chromium. Existing session connections also need their normal lifecycle handling when a route is changed later.