Electron-fensters kinne aparte HTTP-proxyaccounts hawwe

Jou yn aktuele Electron-applikaasjes elke accountspesifike WebContentsView syn eigen neamde sesje. As de app klear is, kin in asynkroane helper yn it haadproses ien werjefte konfigurearje:

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

Jou foar elk isolearre account in apart partitionName en hâld de listenerfariabelen yn 'e closure fan dy werjefte. In namme sûnder persist: makket in sesje yn it ûnthâld. It opnij brûken fan deselde partysje brûkt bewust syn sesjestatus opnij.

Heech de werjefte oan it besteande finster en navigearje pas as syn proxy en handler klear binne. De koade rjochtet him op it hjoeddeiske login-evenemintkontrakt, ynklusyf firstAuthAttempt, en annulearret in wegere werhelle poging ynstee fan itselde account einleas opnij te stjoeren.

De handler kontrolearret dat de útdaging fan 'e bedoelde Basic HTTP-proxy komt. Oanmelde by in webside is net jildich foar dizze gegevens.

Proxyregels kieze it einpunt; login leveret it account. PAC-bestannen en manuele proxyregels drage it wachtwurd fan dizze callback net sels.

Dit is HTTP-proxy-autentikaasje. It foeget gjin SOCKS5-autentikaasje ta oan Chromium. Besteande sesjeferbiningen hawwe ek har normale libbenssyklusbehear nedich as in rûte letter feroare wurdt.