As vistas do Electron podem ter contas de proxy HTTP separadas
Crie uma sessão específica de cada conta para cada WebContentsView e responda apenas ao desafio Basic do proxy correspondente a essa vista.
Nas aplicações Electron atuais, dê a cada WebContentsView associada a uma conta a sua própria sessão nomeada. Quando a aplicação estiver pronta, um assistente assíncrono no processo principal pode configurar uma 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();
});
Forneça um partitionName distinto para cada conta isolada e mantenha as variáveis do ouvinte no closure dessa vista. Um nome sem persist: cria uma sessão em memória. Reutilizar a mesma partição reutiliza deliberadamente o seu estado de sessão.
Anexe a vista à janela existente e navegue apenas quando o proxy e o manipulador estiverem prontos. O código segue o contrato atual do evento login, incluindo firstAuthAttempt, e cancela uma tentativa repetida rejeitada em vez de reenviar a mesma conta indefinidamente.
O manipulador verifica que o desafio vem do proxy Basic HTTP pretendido. O início de sessão de um site não é elegível para essas credenciais.
As regras de proxy escolhem o ponto final; o login fornece a conta. Os ficheiros PAC e as regras de proxy manuais não transportam por si a palavra-passe deste callback.
Isto é autenticação de proxy HTTP. Não acrescenta autenticação SOCKS5 ao Chromium. As ligações de sessão existentes também precisam do tratamento habitual do ciclo de vida quando uma rota é alterada mais tarde.