Az Electron-nézetek külön HTTP-proxyfiókokkal rendelkezhetnek

A jelenlegi Electron-alkalmazásokban minden fiókhoz tartozó WebContentsView kapja meg a saját elnevezett munkamenetét. Amikor az alkalmazás elkészült, a főfolyamat aszinkron segédje beállíthat egy nézetet:

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

Minden elkülönített fiókhoz adjon külön partitionName értéket, és tartsa a figyelő változóit az adott nézet closure-jében. A persist: nélküli név memóriabeli munkamenetet hoz létre. Ugyanazon partíció újrafelhasználása szándékosan újrahasználja annak munkamenet-állapotát.

Csatolja a nézetet a meglévő ablakhoz, és csak akkor navigáljon, amikor a proxy és a kezelő készen áll. A kód a jelenlegi login-eseményszerződést célozza, beleértve a firstAuthAttempt mezőt, és egy elutasított ismételt kísérletet megszakít ahelyett, hogy ugyanazt a fiókot végtelenül újraküldené.

A kezelő ellenőrzi, hogy a kihívás a szándékolt Basic HTTP proxytól érkezik. Egy webhely bejelentkezése nem jogosult ezekre a hitelesítő adatokra.

A proxy-szabályok választják ki a végpontot; a login szolgáltatja a fiókot. A PAC-fájlok és a kézi proxy-szabályok önmagukban nem hordozzák ennek a callbacknek a jelszavát.

Ez HTTP-proxy-hitelesítés. Nem ad hozzá SOCKS5-hitelesítést a Chromiumhoz. A meglévő munkamenet-kapcsolatoknak is szükségük van a szokásos életciklus-kezelésre, amikor egy útvonal később megváltozik.