Electron दृश्यांसाठी वेगळी HTTP प्रॉक्सी खाती असू शकतात

सध्याच्या Electron ॲप्समध्ये, खात्याशी जोडलेल्या प्रत्येक WebContentsView ला त्याचे स्वतःचे नाव असलेले सत्र द्या. ॲप तयार झाल्यावर, मुख्य प्रक्रियेतील async सहाय्यक एक दृश्य कॉन्फिगर करू शकतो:

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 प्रॉक्सी प्रमाणीकरण आहे. ते Chromium मध्ये SOCKS5 प्रमाणीकरण जोडत नाही. नंतर मार्ग बदलल्यास विद्यमान सत्र कनेक्शनलाही त्यांचे नेहमीचे जीवनचक्र व्यवस्थापन लागते.