Electron-visninger kan ha egne HTTP-proxykontoer

I dagens Electron-programmer skal hver kontospesifikke WebContentsView ha sin egen navngitte økt. Når programmet er klart, kan en asynkron hjelper i hovedprosessen konfigurere én visning:

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

Oppgi en egen partitionName for hver isolerte konto, og hold lyttervariablene i den visningens egen closure. Et navn uten persist: oppretter en økt i minnet. Gjenbruk av samme partisjon gjenbruker bevisst øktstatusen.

Fest visningen til det eksisterende vinduet, og naviger først når proxyen og behandleren er klare. Koden følger dagens login-hendelseskontrakt, inkludert firstAuthAttempt, og avbryter et avvist gjentatt forsøk i stedet for å sende den samme kontoen på nytt i det uendelige.

Behandleren kontrollerer at utfordringen kommer fra den tiltenkte Basic HTTP-proxyen. Innlogging på et nettsted er ikke gyldig for disse opplysningene.

Proxyregler velger endepunktet; login leverer kontoen. PAC-filer og manuelle proxyregler bærer ikke selv passordet til denne callbacken.

Dette er HTTP-proxyautentisering. Det legger ikke til SOCKS5-autentisering i Chromium. Eksisterende øktforbindelser trenger også vanlig livssyklushåndtering når en rute endres senere.