Представления Electron могут иметь отдельные учётные записи HTTP-прокси
Создайте сеанс, привязанный к учётной записи, для каждого WebContentsView и отвечайте только на соответствующий запрос Basic-прокси этого представления.
В современных приложениях 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 и ручные правила прокси сами не содержат пароль этого callback.
Это аутентификация HTTP-прокси. Она не добавляет аутентификацию SOCKS5 в Chromium. Существующим соединениям сеанса также требуется обычное управление жизненным циклом, когда маршрут позже меняется.