Authentification SOCKS dans Qt Network et WebEngine
Séparez les paramètres de proxy de Qt Network du comportement de WebEngine basé sur Chromium lorsqu'un service SOCKS exige une authentification.
Une connexion proxy réussie dans Qt Network ne prouve pas que WebEngine prend en charge la même authentification SOCKS. WebEngine utilise Chromium, dont l'implémentation SOCKS5 ne gère pas les méthodes d'authentification ; le traitement de la connexion via un proxy HTTP ne fournit pas cet échange.
QNetworkProxy peut stocker le protocole, l'hôte, le port, le nom d'utilisateur et le mot de passe. Deux consommateurs qui lisent ces champs peuvent néanmoins implémenter des protocoles et des méthodes différents.
Pour comparer un succès dans Network et un échec dans WebEngine, consignez le protocole/la méthode réels du proxy, les versions de Qt/Chromium et l'étape en échec. Choisissez une voie prise en charge par le consommateur qui émet la requête. Pour une navigation publique autorisée avec WebEngine, la liste de proxys SOCKS5 propose des candidats à vérifier pour un accès sans authentification ; utilisez une configuration distincte sans reprendre le nom d'utilisateur ni le mot de passe d'un autre proxy. Une méthode non prise en charge s'arrête avant la connexion au site, si bien que changer le compte de destination traite le mauvais échange.