В съвременните Electron приложения дайте на всеки WebContentsView, свързан с профил, собствена именувана сесия. След като приложението е готово, асинхронен помощник в главния процес може да конфигурира един изглед:

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

Предоставете отделен partitionName за всеки изолиран профил и пазете променливите на слушателя в затварянето на самия изглед. Име без persist: създава сесия в паметта. Повторното използване на един и същ дял умишлено използва повторно състоянието на сесията му.

Прикачете изгледа към съществуващия прозорец и навигирайте едва след като проксито и обработчикът му са готови. Кодът е съобразен с текущия договор на събитието login, включително firstAuthAttempt, и отменя отхвърлен повторен опит, вместо да изпраща същия профил отново безкрайно.

Обработчикът проверява, че предизвикателството идва от предвиденото Basic HTTP прокси. Влизането в уебсайт не е допустимо за тези данни.

Правилата за прокси избират крайната точка; login подава профила. PAC файловете и ръчните правила за прокси сами по себе си не носят паролата на този callback.

Това е удостоверяване за HTTP прокси. То не добавя SOCKS5 удостоверяване към Chromium. Съществуващите връзки на сесията също се нуждаят от нормално управление на жизнения цикъл, когато маршрутът се промени по-късно.

Подобни статии