As vistas de Electron poden ter contas de proxy HTTP separadas
Cree unha sesión específica de cada conta para cada WebContentsView e responda só ao desafío Basic do proxy correspondente a esa vista.
Nas aplicacións Electron actuais, dea a cada WebContentsView asociado a unha conta a súa propia sesión con nome. Cando a aplicación estea lista, un asistente asíncrono do proceso principal pode configurar unha 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 conta illada e manteña as variables do oínte no closure desa vista. Un nome sen persist: crea unha sesión en memoria. Reutilizar a mesma partición reutiliza deliberadamente o seu estado de sesión.
Anexe a vista á xanela existente e navegue só cando o seu proxy e o seu controlador estean listos. O código axústase ao contrato actual do evento login, incluído firstAuthAttempt, e cancela un intento repetido rexeitado en lugar de reenviar a mesma conta indefinidamente.
O controlador comproba que o desafío procede do proxy Basic HTTP previsto. O inicio de sesión dun sitio web non é válido para estas credenciais.
As regras de proxy elixen o punto final; login achega a conta. Os ficheiros PAC e as regras de proxy manuais non levan por si mesmos o contrasinal deste callback.
Isto é autenticación de proxy HTTP. Non engade autenticación SOCKS5 a Chromium. As conexións de sesión existentes tamén necesitan o seu tratamento habitual do ciclo de vida cando se cambia unha ruta máis adiante.