Electron-visninger kan have separate HTTP-proxykonti

I aktuelle Electron-programmer skal hver kontospecifik WebContentsView have sin egen navngivne session. Når programmet er klar, kan en asynkron hjælper i hovedprocessen 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();
});

Angiv en særskilt partitionName for hver isoleret konto, og hold lyttervariablerne i netop den visnings closure. Et navn uden persist: opretter en session i hukommelsen. Genbrug af samme partition genbruger bevidst dens sessionstilstand.

Fastgør visningen til det eksisterende vindue, og navigér først, når dens proxy og handler er klar. Koden rammer den aktuelle login-hændelseskontrakt, inklusive firstAuthAttempt, og annullerer et afvist gentaget forsøg i stedet for at sende den samme konto igen i det uendelige.

Handleren kontrollerer, at udfordringen kommer fra den tilsigtede Basic HTTP-proxy. Et websteds login er ikke gyldigt til disse oplysninger.

Proxyregler vælger slutpunktet; login leverer kontoen. PAC-filer og manuelle proxyregler bærer ikke selv denne callbacks adgangskode.

Dette er HTTP-proxygodkendelse. Det tilføjer ikke SOCKS5-godkendelse til Chromium. Eksisterende sessionsforbindelser har også brug for deres normale livscyklushåndtering, når en rute ændres senere.