Electron-sýn geta haft aðskilda HTTP-proxyreikninga

Búðu til lotu sem er sérstök fyrir hvern reikning fyrir hvert WebContentsView og svaraðu aðeins samsvarandi Basic-proxyáskorun þeirrar sýnar.

Í núverandi Electron-forritum skaltu gefa hverju reikningstengdu WebContentsView sína eigin nefndu lotu. Þegar forritið er tilbúið getur async hjálpari í aðalferlinu stillt eina sýn:

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

Gefðu sérstakt partitionName fyrir hvern einangraðan reikning og haltu hlustunarbreytunum í closure þeirrar sýnar. Nafn án persist: býr til lotu í minni. Endurnýting sama hluta endurnýtir viljandi lotustöðu hans.

Festu sýnina við fyrirliggjandi glugga og farðu aðeins áfram þegar proxy hennar og handler eru tilbúin. Kóðinn miðar við núverandi login-atburðarsamning, þar á meðal firstAuthAttempt, og hættir við hafnaða endurtekna tilraun í stað þess að senda sama reikninginn endalaust aftur.

Handlerinn athugar að áskorunin komi frá fyrirhuguðu Basic HTTP proxy. Innskráning á vefsíðu er ekki gild fyrir þessi skilríki.

Proxyreglur velja endapunktinn; login veitir reikninginn. PAC-skrár og handvirkar proxyreglur bera ekki sjálfar lykilorð þessa callback.

Þetta er HTTP-proxyauðkenning. Hún bætir ekki SOCKS5-auðkenningu við Chromium. Fyrirliggjandi lotutengingar þurfa einnig venjulega lífsferilsmeðferð þegar leið er breytt síðar.

Tengdir greinar