Electron-visingar kan ha eigne HTTP-proxykontoar

I dagens Electron-program skal kvar kontospesifikke WebContentsView ha si eiga namngjevne økt. Når programmet er klart, kan ein asynkron hjelpar i hovudprosessen konfigurera éi vising:

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 ein eigen partitionName for kvar isolerte konto, og hald lyttarvariablane i closure-en til den visinga. Eit namn utan persist: opprettar ei økt i minnet. Gjenbruk av same partisjon gjenbrukar med vilje øktstatusen.

Fest visinga til det eksisterande vindauget, og naviger først når proxyen og handteraren er klare. Koden følgjer dagens login-hendingskontrakt, inkludert firstAuthAttempt, og avbryt eit avvist gjenteke forsøk i staden for å senda den same kontoen på nytt i det uendelege.

Handteraren kontrollerer at utfordringa kjem frå den tiltenkte Basic HTTP-proxyen. Innlogging på ein nettstad er ikkje gyldig for desse opplysningane.

Proxyreglar vel endepunktet; login leverer kontoen. PAC-filer og manuelle proxyreglar ber ikkje sjølve passordet til denne callbacken.

Dette er HTTP-proxyautentisering. Det legg ikkje til SOCKS5-autentisering i Chromium. Eksisterande øktforbindingar treng òg vanleg livssyklushandtering når ei rute blir endra seinare.