Electron-vensters kan afsonderlike HTTP-proxyrekeninge hê

Vir huidige Electron-toepassings gee elkeen rekening-spesifieke WebContentsView sy eie benoemde sessie. Nadat die toepassing gereed is, kan 'n asinchrone helper in die hoofproses een view konfigureer:

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

Verskaf 'n afsonderlike partitionName vir elke geïsoleerde rekening en hou die luisteraarvariabeles in daardie view se eie closure. 'n Naam sonder persist: skep 'n in-geheue-sessie. Hergebruik van dieselfde partisie hergebruik doelbewus sy sessietoestand.

Heg die view aan die bestaande venster en navigeer eers nadat sy proxy en handler gereed is. Die kode teiken die huidige login-gebeurteniskontrak, insluitend firstAuthAttempt, en kanselleer 'n verwerpte herhaalde poging in plaas daarvan om dieselfde rekening onbepaald weer in te dien.

Die handler kontroleer dat die uitdaging van die beoogde Basic HTTP-proxy kom. 'n Webwerf se aanmelding is nie geskik vir daardie geloofsbriewe nie.

Proxyreëls kies die eindpunt; login verskaf die rekening. PAC-lêers en handmatige proxyreëls dra nie self hierdie callback se wagwoord nie.

Dit is HTTP-proxy-verifikasie. Dit voeg nie SOCKS5-verifikasie by Chromium nie. Bestaande sessieverbindings benodig ook hul normale lewensiklushantering wanneer 'n roete later verander word.