Electron приказите можат да имаат одделни HTTP прокси сметки

Во тековните 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. Постоечките сесиски врски исто така бараат вообичаено управување со животниот циклус кога рутата подоцна се менува.