Electron ویوز کے الگ HTTP پراکسی اکاؤنٹس ہو سکتے ہیں
ہر WebContentsView کے لیے اکاؤنٹ کے مخصوص سیشن بنائیں اور صرف اسی ویو کے مطابق Basic پراکسی چیلنج کا جواب دیں۔
موجودہ 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 پراکسی سے آیا ہے۔ ویب سائٹ کا لاگ ان ان اسناد کے لیے اہل نہیں ہے۔
پراکسی قواعد اینڈ پوائنٹ منتخب کرتے ہیں؛ login اکاؤنٹ فراہم کرتا ہے۔ PAC فائلیں اور دستی پراکسی قواعد خود اس callback کا پاس ورڈ نہیں رکھتے۔
یہ HTTP پراکسی تصدیق ہے۔ یہ Chromium میں SOCKS5 تصدیق شامل نہیں کرتی۔ بعد میں راستہ بدلنے پر موجودہ سیشن کنکشنز کو بھی ان کا معمول کا لائف سائیکل انتظام درکار ہوتا ہے۔