Electron-vidoj povas havi apartajn HTTP-proksejajn kontojn

Kreu kontospecifan seancon por ĉiu WebContentsView kaj respondu nur al la kongrua Basic-prokseja defio de tiu vido.

En nunaj Electron-aplikaĵoj, donu al ĉiu kontospecifa WebContentsView sian propran nomitan seancon. Post kiam la aplikaĵo pretas, nesinkrona helpanto en la ĉefa procezo povas agordi unu vidon:

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

Provizu apartan partitionName por ĉiu izolita konto kaj tenu la aŭskultajn variablojn en la fermaĵo de tiu vido. Nomo sen persist: kreas seancon en memoro. Reuzi la saman dividaĵon intence reuzas ĝian seancostaton.

Alligu la vidon al la ekzistanta fenestro kaj navigu nur post kiam ĝia proksejo kaj traktilo pretas. La kodo celas la nunan kontrakton de la login-evento, inkluzive firstAuthAttempt, kaj nuligas malakceptitan ripetan provon anstataŭ senfine resendi la saman konton.

La traktilo kontrolas, ke la defio venas de la celita Basic HTTP-proksejo. Ensaluto de retejo ne validas por tiuj akreditaĵoj.

Proksejaj reguloj elektas la finpunkton; login provizas la konton. PAC-dosieroj kaj manaj proksejaj reguloj mem ne portas la pasvorton de ĉi tiu callback.

Ĉi tio estas HTTP-prokseja aŭtentikigo. Ĝi ne aldonas SOCKS5-aŭtentikigon al Chromium. Ekzistantaj seancaj konektoj ankaŭ bezonas sian kutiman vivciklan traktadon kiam itinero ŝanĝiĝas poste.

Rilataj artikoloj