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: बिनाको नामले इन-मेमोरी सत्र बनाउँछ। उही विभाजन पुन: प्रयोग गर्दा यसको सत्र स्थिति जानाजान पुन: प्रयोग हुन्छ।

भ्युलाई विद्यमान विन्डोमा संलग्न गर्नुहोस् र यसको प्रोक्सी र ह्यान्डलर तयार भएपछि मात्र नेभिगेट गर्नुहोस्। कोडले firstAuthAttempt सहित वर्तमान login घटना सम्झौतालाई लक्षित गर्छ र अस्वीकृत दोहोरिएको प्रयासलाई उही खाता अनिश्चितकाल पुन: पठाउनुको सट्टा रद्द गर्छ।

ह्यान्डलरले चुनौती इच्छित Basic HTTP प्रोक्सीबाट आएको जाँच गर्छ। वेबसाइटको लगइन यी प्रमाणहरूका लागि योग्य छैन।

प्रोक्सी नियमहरूले endpoint छान्छन्; login ले खाता दिन्छ। PAC फाइलहरू र म्यानुअल प्रोक्सी नियमहरूले यो callback को पासवर्ड आफैं बोक्दैनन्।

यो HTTP प्रोक्सी प्रमाणीकरण हो। यसले Chromium मा SOCKS5 प्रमाणीकरण थप्दैन। पछि मार्ग परिवर्तन हुँदा विद्यमान सत्र जडानहरूलाई पनि तिनको सामान्य जीवनचक्र व्यवस्थापन चाहिन्छ।