Las vistas de Electron pueden tener cuentas de proxy HTTP separadas

En las aplicaciones Electron actuales, dé a cada WebContentsView asociado a una cuenta su propia sesión con nombre. Cuando la aplicación esté lista, un asistente asíncrono del proceso principal puede configurar 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();
});

Proporcione un partitionName distinto para cada cuenta aislada y mantenga las variables del oyente en el closure de esa vista. Un nombre sin persist: crea una sesión en memoria. Reutilizar la misma partición reutiliza deliberadamente su estado de sesión.

Adjunte la vista a la ventana existente y navegue solo cuando su proxy y su controlador estén listos. El código se ajusta al contrato actual del evento login, incluido firstAuthAttempt, y cancela un intento repetido rechazado en lugar de reenviar la misma cuenta indefinidamente.

El controlador comprueba que el desafío proviene del proxy Basic HTTP previsto. El inicio de sesión de un sitio web no es válido para estas credenciales.

Las reglas de proxy eligen el extremo; login aporta la cuenta. Los archivos PAC y las reglas de proxy manuales no llevan por sí mismos la contraseña de este callback.

Esto es autenticación de proxy HTTP. No añade autenticación SOCKS5 a Chromium. Las conexiones de sesión existentes también necesitan su gestión habitual del ciclo de vida cuando se cambia una ruta más adelante.