Les vues Electron peuvent avoir des comptes de proxy HTTP distincts

Dans les applications Electron actuelles, donnez à chaque WebContentsView associé à un compte sa propre session nommée. Une fois l'application prête, un assistant asynchrone du processus principal peut configurer une vue :

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();
});

Fournissez un partitionName distinct pour chaque compte isolé et gardez les variables d'écoute dans la fermeture de cette vue. Un nom sans persist: crée une session en mémoire. Réutiliser la même partition réutilise délibérément son état de session.

Attachez la vue à la fenêtre existante et ne naviguez qu'une fois son proxy et son gestionnaire prêts. Le code vise le contrat actuel de l'événement login, y compris firstAuthAttempt, et annule une tentative répétée refusée au lieu de soumettre indéfiniment le même compte.

Le gestionnaire vérifie que le défi provient du proxy Basic HTTP prévu. La connexion d'un site web n'est pas éligible pour ces identifiants.

Les règles de proxy choisissent le point de terminaison ; login fournit le compte. Les fichiers PAC et les règles de proxy manuelles ne portent pas eux-mêmes le mot de passe de ce callback.

Il s'agit d'une authentification de proxy HTTP. Elle n'ajoute pas d'authentification SOCKS5 à Chromium. Les connexions de session existantes ont aussi besoin de leur gestion habituelle du cycle de vie lorsqu'un itinéraire change plus tard.