SOCKS-aŭtentikigo en Qt Network kaj WebEngine
Apartigu la proksilan agordaron de Qt Network de la konduto de WebEngine bazita sur Chromium kiam SOCKS-servo postulas aŭtentikigon.
Funkcianta proksila ensaluto en Qt Network ne pruvas, ke WebEngine subtenas la saman SOCKS-aŭtentikigon. WebEngine uzas Chromium, kies SOCKS5-realigo mankas subtenon por aŭtentikigaj metodoj; la traktado de HTTP-proksila ensaluto ne donas tiun interŝanĝon.
QNetworkProxy povas konservi protokolon, gastiganton, pordon, uzantnomon kaj pasvorton. Du konsumantoj legantaj tiujn kampojn tamen povas realigi malsamajn protokolojn kaj metodojn.
Por komparo „Network sukcesas / WebEngine malsukcesas“, notu la faktan proksilan protokolon/metodon, la versiojn de Qt/Chromium kaj la malsukcesan stadion. Elektu vojon subtenatan de la konsumanto, kiu faras la peton. Por permesita publika retumado per WebEngine, la listo de SOCKS5-proksiloj proponas kandidatojn por kontroli aliron sen aŭtentikigo; uzu apartan agordon sen transdoni la uzantnomon aŭ pasvorton de alia proksilo. Nesubtenata metodo haltas antaŭ la reteja ensaluto, do ŝanĝi la celan konton traktas la malĝustan interŝanĝon.