Electron-vyer kan ha separata HTTP-proxykonton

I nuvarande Electron-appar ska varje kontospecifik WebContentsView ha sin egen namngivna session. När appen är redo kan en asynkron hjälpare i huvudprocessen konfigurera en vy:

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

Ange en separat partitionName för varje isolerat konto och håll lyssnarvariablerna i den vyns egen closure. Ett namn utan persist: skapar en session i minnet. Återanvändning av samma partition återanvänder medvetet dess sessionsstatus.

Fäst vyn vid det befintliga fönstret och navigera först när dess proxy och hanterare är redo. Koden följer det aktuella login-händelseavtalet, inklusive firstAuthAttempt, och avbryter ett avvisat upprepat försök i stället för att skicka samma konto igen i oändlighet.

Hanteraren kontrollerar att utmaningen kommer från den avsedda Basic HTTP-proxyn. Inloggning på en webbplats är inte giltig för dessa uppgifter.

Proxyregler väljer slutpunkten; login levererar kontot. PAC-filer och manuella proxyregler bär inte själva denna callbacks lösenord.

Detta är HTTP-proxyautentisering. Det lägger inte till SOCKS5-autentisering i Chromium. Befintliga sessionsanslutningar behöver också sin vanliga livscykelhantering när en rutt ändras senare.