Pamjet Electron mund të kenë llogari të veçanta HTTP proxy

Në aplikacionet aktuale Electron, jepini çdo WebContentsView të lidhur me një llogari sesionin e vet të emërtuar. Pasi aplikacioni të jetë gati, një ndihmës async në procesin kryesor mund të konfigurojë një pamje:

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

Jepni një partitionName të veçantë për secilën llogari të izoluar dhe mbani variablat e dëgjuesit në closure-in e asaj pamjeje. Një emër pa persist: krijon një sesion në memorie. Ripërdorimi i të njëjtës ndarje ripërdor me qëllim gjendjen e sesionit të saj.

Lidhni pamjen me dritaren ekzistuese dhe navigoni vetëm pasi proxy-t dhe trajtuesi i saj të jenë gati. Kodi synon kontratën aktuale të ngjarjes login, duke përfshirë firstAuthAttempt, dhe anulon një përpjekje të përsëritur të refuzuar në vend që ta ridërgojë pa fund të njëjtën llogari.

Trajtuesi kontrollon që sfida vjen nga proxy-ti Basic HTTP i synuar. Hyrja në një sajt nuk është e vlefshme për këto kredenciale.

Rregullat e proxy-t zgjedhin pikën fundore; login siguron llogarinë. Skedarët PAC dhe rregullat manuale të proxy-t nuk e mbajnë vetë fjalëkalimin e këtij callback.

Kjo është vërtetim proxy HTTP. Nuk shton vërtetim SOCKS5 në Chromium. Lidhjet ekzistuese të sesionit gjithashtu kanë nevojë për trajtimin e zakonshëm të ciklit të jetës kur një itinerar ndryshohet më vonë.