نماهای 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 است. احراز هویت SOCKS5 را به Chromium اضافه نمی‌کند. اتصال‌های نشست موجود نیز هنگام تغییر مسیر در آینده به مدیریت چرخه عمر معمول خود نیاز دارند.