Подання Electron можуть мати окремі облікові записи HTTP-проксі

Створіть сеанс, прив’язаний до облікового запису, для кожного WebContentsView і відповідайте лише на відповідний запит Basic-проксі цього подання.

У сучасних застосунках 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. Наявні з’єднання сеансу також потребують звичайного керування життєвим циклом, коли маршрут згодом змінюється.

Схожі статті