xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 8 weeks ago

Last modified 8 weeks ago

#2874 closed enhancement (fixed)

Feature requests for Xpra Launcher File

Reported by: Mark Harkin Owned by: Mark Harkin
Priority: major Milestone: 4.1
Component: server Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

I'm working on trunk r27446 (Ubuntu / Alpine servers, Windows client)

I'm chasing a use case where a user logs into a webpage using Authelia 2 factor login (https://github.com/authelia/authelia).
The user then gets prompted to download a generated .xpra file with client side javascript picking up authelia session cookie. The user then opens this file to have a fully configured xpra ws session.

What I think is needed for this:

  • (possible bug) "Xpra-launcher.exe ..." doesn't pick up conf from etc conf files, whereas "Xpra.exe launcher ..." does.
  • (possible bug) when building, server side only supports zlib whereas client is supporting lz4 and lzo also (seen on ubuntu and alpine build).
  • (request) It would be very nice to be able to set .conf properties in the .xpra file. env vars specifically for the below.
  • (request) For xpra ws connection to connect through authelia's mechanism we need to set a cookie session id in the header, this can be grabbed from javascript webpage and set into a generated .xpra file, but is it possible to allow setting a custom header on the websocket connection through the use of a env var?
  • (nice to have) maybe through flags, hide launcher after successful connection, restore if failed connection, close if disconnected.
  • (nice to have) not required for me but might be nice to offer the .xpra download option on the html login page, which would generate based on form values.

Appreciate your input.

Change History (11)

comment:1 Changed 2 months ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to Mark Harkin

(possible bug) "Xpra-launcher.exe ..." doesn't pick up conf from etc conf files, whereas "Xpra.exe launcher ..." does.

Fixed in #2878

(possible bug) when building, server side only supports zlib whereas client is supporting lz4 and lzo also (seen on ubuntu and alpine build).

That would be a bug. But I don't see that here:

$ xpra info | grep -i network.lz4
network.lz4.python-lz4=True
network.lz4.python-lz4.version=3.0.2
network.lz4.version=3.0.2
$ ./xpra/net/net_util.py | grep lz4
* compressors                     : zlib, lz4, lzo, brotli, none
* lz4
  - python-lz4                    : True

Which Ubuntu release and how did you ascertain this?

(request) It would be very nice to be able to set .conf properties in the .xpra file. env vars specifically for the below.

I don't really understand this one. How is that different from #2878?

(request) For xpra ws connection to connect through authelia's mechanism we need to set a cookie session id in the header, this can be grabbed from javascript webpage and set into a generated .xpra file, but is it possible to allow setting a custom header on the websocket connection through the use of a env var?

Should be easy to add. Can't you just use #1741 for that?

(nice to have) maybe through flags, hide launcher after successful connection, restore if failed connection, close if disconnected.

That's what it does. works-for-me(tm)

(nice to have) not required for me but might be nice to offer the .xpra download option on the html login page, which would generate based on form values.

Nice idea: #2881

comment:2 Changed 2 months ago by Mark Harkin

Think I'll work on this a bit more over the next few days and get back when I've something more polished.
Just committed a quick 1st attempt but I guess there'll have to be some more remapping of properties. https://github.com/mjharkin/Xpra/commit/617949ec658f70bd2d21351aefe69610edb5f79b

For authelia intend to set env var from session cookie on webpage so #1741 isn't dyanmic enough, I've implemented it as https://github.com/mjharkin/Xpra/commit/aa83eb8a6b9f36350d6d271c278a91421e796aa1

For compression (Ubuntu 20.04 and Alpine 3.12.0) also getting the following but from the client session info gui the server only has lz4 compression might be an issue with the capabilities being sent

network.lz4.python-lz4=True
network.lz4.python-lz4.version=3.0.2+dfsg
network.lz4.version=3.0.2+dfsg

comment:3 Changed 2 months ago by Mark Harkin

@Antoine Martin
I've almost everything for this now, so remaining are:

  • Websocket cookies for python client - intended to use javascript to read the cookies but can't do this with httpOnly cookies, so need the python client to read them instead. This only supports Chrome or Firefox but as it's opt in, I'd appreciate if this could be added https://github.com/mjharkin/Xpra/commit/7616aba061e9fde2b2bf0ab5bdf66c26fd721738 and requires browser_cookie3 package. Use case is: user logs in to authelia protected webpage (connect.html) cookies are created in browser. User launches generated xpra file and python client adds cookies from the browser. Not as clean as I was hoping for but maybe more secure and I've tested this with both authelia session cookie and traefik sticky sessions which look good.
  • I think mimetypes.py is missing from the windows build, for now I'm just copying it in manually, not sure how it should be added to the build.

comment:4 Changed 2 months ago by Antoine Martin

Websocket cookies for python client

I think this is a better, more modular solution: r27604.
You can now achieve the same result by configuring your client with:

XPRA_WS_COOKIE=hello XPRA_WEBSOCKET_HEADERS_MODULES=default,env_cookie,browser_cookie xpra attach ws://$HOST:$PORT/

And we can also easily add more header modules when needed.
I didn't have your copyright details, so I just put mjharkin, let me know what you want this changed to.

I think mimetypes.py is missing from the windows build

What was the error you saw?
r27603 fixes that. (should I backport it?)

html5 client fullscreen

Your fix was correct.
r27605 does the same and a bit more.

comment:5 in reply to:  4 Changed 2 months ago by Mark Harkin

Replying to Antoine Martin:

Websocket cookies for python client

I think this is a better, more modular solution: r27604.

works very well thanks.
For the windows client to build I added this but you may want to make it conditional.
https://github.com/mjharkin/Xpra/commit/e725f19f1c6a8ba0e24cffd6257d7ddb1295f58a

I didn't have your copyright details, so I just put mjharkin, let me know what you want this changed to.

Please copyright under your own name... and same goes for any future changes I submit.

I think mimetypes.py is missing from the windows build

What was the error you saw?

Original client failing message was:

2020-10-06 09:46:15,211 Warning: failed to connect:
2020-10-06 09:46:15,214  cannot handle websocket connection: No module named 'mimetypes'


r27603 fixes that. (should I backport it?)

Fails to build because mimetypes.py is in root python folder not site-packages, again not sure how to handle this. No need from my side to backport.

ERROR: build failed, see win32/cx_freeze-install.log:
    self.run_command(cmd)
  File "C:/msys64/mingw64/lib/python3.8/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "C:/msys64/mingw64/lib/python3.8/site-packages/cx_Freeze/dist.py", line 297, in run
    self.run_command('build_exe')
  File "C:/msys64/mingw64/lib/python3.8/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:/msys64/mingw64/lib/python3.8/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "C:/msys64/mingw64/lib/python3.8/site-packages/cx_Freeze/dist.py", line 211, in run
    freezer.Freeze()
  File "C:/msys64/mingw64/lib/python3.8/site-packages/cx_Freeze/freezer.py", line 610, in Freeze
    self.finder = self._GetModuleFinder()
  File "C:/msys64/mingw64/lib/python3.8/site-packages/cx_Freeze/freezer.py", line 354, in _GetModuleFinder
    finder.IncludeModule(name)
  File "C:/msys64/mingw64/lib/python3.8/site-packages/cx_Freeze/finder.py", line 631, in IncludeModule
    module = self._ImportModule(name, deferredImports,
  File "C:/msys64/mingw64/lib/python3.8/site-packages/cx_Freeze/finder.py", line 348, in _ImportModule
    raise ImportError("No module named %r" % name)
ImportError: No module named 'mimetypes'

html5 client fullscreen

Your fix was correct.
r27605 does the same and a bit more.

Working, thanks.

comment:6 Changed 2 months ago by Antoine Martin

For the windows client to build I added this but you may want to make it conditional.

r27617, commented out for now.
I'll try to see how much weight this adds to the installer first.

Original client failing message was:

Ah, yes.
The unit tests run from the MSYS2 env, so they don't catch the missing dependency.
And I almost never test websocket connections with the python client since there are no advantages over plain tcp connections. (just an extra packet header)

Fails to build because mimetypes.py is in root python folder not site-packages, again not sure how to handle this.

Works fine for me(tm). And I've made quite a few mswindows builds these past few days.

$ python -c "import mimetypes;print(mimetypes.__file__)"
C:/msys64/mingw64/lib/python3.8/mimetypes.py

No need from my side to backport.

If websocket connections are broken, I have to..

comment:7 in reply to:  6 Changed 8 weeks ago by Mark Harkin

Replying to Antoine Martin:

r27617, commented out for now.
I'll try to see how much weight this adds to the installer first.

No problem, understand it's edge case. adds about 100KB uncompressed.

Works fine for me(tm). And I've made quite a few mswindows builds these past few days.

Think I've found the issue here, I'm building CLIENT_ONLY which is causing --without-html5 flag, Possibly remove mimetypes from exclude in setup.py at line 384?

Just to note, as I guess you haven't seen this issue. I had to downgrade cx_freeze from 6.2 to 6.1 as I was getting this error in 6.2:

* Generating installation directory
ERROR: build failed, see win32/cx_freeze-install.log:
    self.run_command(cmd)
  File "C:/msys64/mingw64/lib/python3.8/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "C:/msys64/mingw64/lib/python3.8/site-packages/cx_Freeze/dist.py", line 299, in run
    self.run_command('build_exe')
  File "C:/msys64/mingw64/lib/python3.8/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:/msys64/mingw64/lib/python3.8/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "C:/msys64/mingw64/lib/python3.8/site-packages/cx_Freeze/dist.py", line 217, in run
    freezer.Freeze()
  File "C:/msys64/mingw64/lib/python3.8/site-packages/cx_Freeze/freezer.py", line 645, in Freeze
    self._WriteModules(fileName, self.finder)
  File "C:/msys64/mingw64/lib/python3.8/site-packages/cx_Freeze/freezer.py", line 536, in _WriteModules
    sourcePackageDir = os.path.dirname(module.file)
  File "C:/msys64/mingw64/lib/python3.8/ntpath.py", line 238, in dirname
    return split(p)[0]
  File "C:/msys64/mingw64/lib/python3.8/ntpath.py", line 200, in split
    p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not NoneType

Also tried to test the beta zip (r27616) but have issue on a wss connection:

2020-10-06 18:20:19,762  connection failed: DLL load failed while importing _ssl: The specified procedure could not be found.

comment:8 Changed 8 weeks ago by Antoine Martin

No problem, understand it's edge case. adds about 100KB uncompressed.

100KB is OK, so this is now enabled by default: r27628.

Think I've found the issue here, I'm building CLIENT_ONLY which is causing --without-html5 flag, Possibly remove mimetypes from exclude in setup.py at line 384?

I believe this may have been fixed just yesterday by r27622.
Are you still having this problem?

Just to note, as I guess you haven't seen this issue. I had to downgrade cx_freeze from 6.2 to 6.1 as I was getting this error in 6.2:

See one liner fix in #2846.

Also tried to test the beta zip (r27616) but have issue on a wss connection:
connection failed: DLL load failed while importing _ssl: The specified procedure could not be found.

I'm not seeing any problems here and I've tested the latest builds on a clean MSEdge VM from Microsoft..
Can you try the very latest beta build? (I've made CLIENT_ONLY=1 4.1 beta)


And assuming this also works for you, please (finally) close this ticket.
(better to keep one issue per ticket too)

comment:9 in reply to:  8 Changed 8 weeks ago by Mark Harkin

Resolution: fixed
Status: newclosed

Replying to Antoine Martin:

100KB is OK, so this is now enabled by default: r27628.

Appreciated, thanks.

I believe this may have been fixed just yesterday by r27622.
Are you still having this problem?

Thanks, working now after r27622

See one liner fix in #2846.

Thanks, I'll apply it.

I'm not seeing any problems here and I've tested the latest builds on a clean MSEdge VM from Microsoft..
Can you try the very latest beta build? (I've made CLIENT_ONLY=1 4.1 beta)

Still seeing the issue on r27631 beta and not in custom builds, I'll investigate a bit more and raise another ticket if needed.

And assuming this also works for you, please (finally) close this ticket.
(better to keep one issue per ticket too)

Absolutely, noted. I'll close, thanks for all of this.

comment:10 Changed 8 weeks ago by Antoine Martin

Still seeing the issue on r27631 beta and not in custom builds, I'll investigate a bit more and raise another ticket if needed.

Maybe your %PATH% is polluted with another conflicting version of the same DLL?

I've re-checked and tested ssl as well as wss connections without any problems.

comment:11 in reply to:  10 Changed 8 weeks ago by Mark Harkin

Replying to Antoine Martin:

I've re-checked and tested ssl as well as wss connections without any problems.

Yes, just tried on another PC and it's working, so I'll look at correcting the local setup, thanks.

Note: See TracTickets for help on using tickets.