يمكن لنوافذ 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 مميزًا لكل حساب معزول واحتفظ بمتغيرات المستمع في الإغلاق الخاص بذلك العرض. الاسم الذي لا يحتوي على persist: ينشئ جلسة في الذاكرة. إعادة استخدام القسم نفسه تعيد استخدام حالة جلسته عمدًا.

أرفق العرض بالنافذة الموجودة ولا تنتقل إلا بعد جاهزية الوكيل والمعالج الخاص به. يستهدف الكود عقد حدث login الحالي، بما في ذلك firstAuthAttempt، ويلغي المحاولة المتكررة المرفوضة بدلًا من إعادة إرسال الحساب نفسه إلى ما لا نهاية.

يتحقق المعالج من أن التحدي صادر عن وكيل Basic HTTP المقصود. تسجيل الدخول إلى موقع ويب ليس مؤهلًا لهذه البيانات.

قواعد الوكيل تختار نقطة النهاية؛ وlogin يوفّر الحساب. لا تحمل ملفات PAC وقواعد الوكيل اليدوية كلمة مرور هذا الاستدعاء بحد ذاتها.

هذه مصادقة وكيل HTTP. وهي لا تضيف مصادقة SOCKS5 إلى Chromium. كما تحتاج اتصالات الجلسة القائمة إلى معالجة دورة حياتها المعتادة عند تغيير المسار لاحقًا.