Прагляды 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 для кожнага ізаляванага ўліковага запісу і трымайце зменныя слухача ў closure самога прагляду. Імя без persist: стварае сеанс у памяці. Паўторнае выкарыстанне таго ж раздзела наўмысна выкарыстоўвае яго стан сеансу.

Далучыце прагляд да існуючага акна і пераходзьце толькі пасля гатоўнасці яго праксі і апрацоўшчыка. Код разлічаны на бягучы кантракт падзеі login, уключаючы firstAuthAttempt, і адмяняе адхіленую паўторную спробу замест бясконцай паўторнай адпраўкі таго ж уліковага запісу.

Апрацоўшчык правярае, што выклік паходзіць ад мэтавага Basic HTTP-праксі. Уваход на вэб-сайт не падыходзіць для гэтых даных.

Правілы праксі выбіраюць канчатковую кропку; login падае ўліковы запіс. Файлы PAC і ручныя правілы праксі самі не нясуць пароль гэтага callback.

Гэта аўтэнтыфікацыя HTTP-праксі. Яна не дадае аўтэнтыфікацыю SOCKS5 у Chromium. Існуючыя злучэнні сеансу таксама патрабуюць звычайнага кіравання жыццёвым цыклам, калі маршрут пазней зменіцца.

Падобныя артыкулы