Add support for "attach" through the forward proxy (with authentication).

[Laxhy]

To connect from a secure site to an external xpra server, it is necessary to use a "forward proxy".

Add parameters for the possibility of proxy definition, similar to what is possible with java.

Thx

[totaam]

That's already possible and should even be auto-detected on platforms where libproxy is available: #2105

[Laxhy]

Thanks for you answer,
since which version is this feature available? I can't do it on windows at the moment.

xpra v4.4.3-r0

xpra attach wss://10.79.13.1/ris/29/78FFC43FD152356FB23ED54C4A2D05CD6C07706E/6?proxy-port=18888&proxy-host=10.77.1.3&proxy-username=user&proxy-password=password --ssl-server-verify=none --ssl-ca-data=4261672041747472....2d2d0a


'proxy-host' is not recognized as an internal or external command,
operable program or batch file.
'proxy-username' is not recognized as an internal or external command,
operable program or batch file.
'proxy-password' is not recognized as an internal or external command,
operable program or batch file.

Thx

[totaam]

@Laxhy Your URI has & in it and this is being interpreted by your shell.
Either quote it or escape it.

This proxy feature is available in 4.4.x and later.

Also, if you're on MS Windows, you should be using xpra_cmd.exe not xpra, so that you can see the diagnostics.
I'm also not sure why you're using a native client with a wss URL, that's usually just wasting bandwidth - unless you really need it because you use some kind of reverse proxy at the other end.

[Laxhy]

• problem with & soled, I'm ashamed :)
• wss/ws - yes, intergration flow is "client (win, macos, lnux) -> forwarding proxy -> reverse proxy -> xpra server"
• xpra_cmd (yes we use xpra_cmd for windows) copy-paste error, sorry

Thanks a lot

[Laxhy]

@totaam I have one more question. (It is possible that it is a problem on the side of the proxy server). But I will try to ask:

Log from the client site:

2022-12-08 09:28:33,488 Xpra GTK3 client version 4.4.3-r0 64-bit
2022-12-08 09:28:33,504  running on Microsoft Windows 2012ServerR2
2022-12-08 09:28:35,381 GStreamer version 1.20.4
2022-12-08 09:28:35,522 created named pipe 'Xpra\2184'
2022-12-08 09:28:35,662  cannot load dec_nvjpeg (nvjpeg decoder)
Traceback (most recent call last):
 File "E:/xpra/xpra/codecs/loader.py", line 81, in codec_import_check
 File "xpra/codecs/nvjpeg/decoder.pyx", line 28, in init xpra.codecs.nvjpeg.decoder
 File "E:/xpra/xpra/codecs/cuda_common/cuda_context.py", line 29, in <module>
 File "C:/msys64/mingw64/lib/python3.10/site-packages/pycuda-2022.2-py3.10-mingw_x86_64.egg/pycuda/driver.py", line 60, in <module>
 File "C:/msys64/mingw64/lib/python3.10/site-packages/pycuda-2022.2-py3.10-mingw_x86_64.egg/pycuda/driver.py", line 35, in _add_cuda_libdir_to_dll_path
 File "C:/msys64/mingw64/lib/python3.10/os.py", line 1118, in add_dll_directory
FileNotFoundError: [WinError 2] The system cannot find the file specified: 'C:\\Program Files\\Xpra\\bin\\bin'
2022-12-08 09:28:35,709 keyboard layout 'United States - English' : 'us' (0x409)
 Warning: failed to connect:
 **connection failed: Socket error: SOCKS5 proxy server sent invalid data**

On the proxy server:

2022/12/08 09:30:24 [info] 14805#14805: *1999 client sent invalid method while reading client request line, client: 10.79.1.1, server: , request: "^E^B^@^B"
2022/12/08 09:30:24 [info] 14805#14805: *1999 recv() failed (104: Connection reset by peer) while reading client request line, client: 10.79.1.1, server: , request: "^E^B^@^B"

It's probably an SSL problem, but I have no idea what to do with it :(

Thx

[totaam]

FileNotFoundError: [WinError 2] The system cannot find the file specified: 'C:\\Program Files\\Xpra\\bin\\bin'

This one is unrelated and this is news to me! Caused by 31f2d62 and fixed by 919036d

---

As for the socks proxy error Socket error: SOCKS5 proxy server sent invalid data
This one comes from the proxy library directly and the entire call site can be seen here:

xpra/xpra/scripts/main.py

Lines 920 to 930 in 70b897e

	host = to.strget("proxy-host")
	port = to.intget("proxy-port", 1080)
	rdns = to.boolget("proxy-rdns", True)
	username = options.get("proxy-username")
	password = options.get("proxy-password")
	timeout = options.get("timeout", 20)
	sock = socks.socksocket()
	sock.set_proxy(proxy_type, host, port, rdns, username, password)
	sock.settimeout(timeout)
	sock.connect((options["host"], options["port"]))
	return sock

That's because PySocks does not support SSL: Anorov/PySocks#29

Perhaps we should add a big warning message that ssl connections will bypass the proxy settings?