[winswitch] HTML Client - howto and problems

[Antoine Martin]

On 07/06/2022 12:18, xpra--- via shifter-users wrote:
> 
> Using Xpra 4.3.3 on Kubuntu 20.04....both server and client.
> 
> I am testing out the HTML client to possibly allow for use case when SSH 
> and X11 is not available, but a web browser is... but I run into some 
> issues
> 
> 1) Proper server startup ??
> 
> Following the wiki, man page and numerous sites adding
Can you please specify the wiki page so that I can amend it?

> --bind-tcp=0.0.0.0:14500 --html=on should do the trick, correct?
The html5 client documentation uses port 10000, which is usually free:
https://github.com/Xpra-org/xpra-html5#usage

> No joy, UNLESS I REMOVE the --bind-tcp option... then the Xpra server 
> will start. otherwise get an error about already in use on 0.0.0.0 ...
That's because the xpra package runs a proxy server on port 14500 so you 
cannot start another server on the same port.

Connecting via the proxy is possible and it should work, but you may 
want to skip it altogether to simplify things - especially when 
encountering issues.

> So has this changed and the bind is automatic by default????? Or????
> 
> So I add --html=on to the startup
That doesn't make any difference, it is the default.
> 
> xpra start --html=on --env=XPRA_VAAPI=0 --env=CUTTER_THRESHOLD=0 :100 
> --start=/home/theprogramIstartup
"--env=XPRA_VAAPI=0" is also the default.

> That works.... everything starts... I can use xpra-connect and connect.. 
> good to go on my normal mode...
> 
> 2) Access THE SESSION ABOVE VIA THE HTML5 client
> 
> goto https://1.2.3.4:14500/connect.html
> 
> OK.. get the login box....ok..
> 
> a) First issue:
> 
>   Connect option:  "NO SESSIONS FOUND" in red
> 
> 
>   I am taking this "connect" option would be what I do via the 
> xpra_connect setup I have, already, connect up to the running XPRA on 
> :100 let me see what its doing, etc., disconnect come back to it as 
> needed.. Thats my use case mostly, check up on a program that runs long 
> term...
> 
> Is that correct for this connect option???????
This option is similar to what can be done via "xpra sessions".

But if the proxy server doesn't see the server you started, it is 
unlikely to work.

> b) Second issue:
> 
> Using the SHADOW OPTION and it gives a drop down, :0, obviously the 
> desktop thats there.. and then :100 which is the session I STARTED 
> ABOVE... OK... select shadow and :100 from the drop down...
> 
> Connects up, and after the initial transfer, I get session :0,  NOT 
> :100.. Doesn't matter how many times I change the dropdown from :0 to 
> :100 it will NOT CONNECT TO THAT :100 session in shadow
> 
> UMMMM????????
Sounds like a bug.
The "xpra start" session on ":100" should have shown up in the "connect" 
list, not in the "shadow" list.

> c) Infinite loop connection
> 
> IF you try the connection LOCALLY ON THE SAME BOX as the server via 
> HTML5 client in browser, because it is shadowing :0 it just causes an 
> infinite loop where the browser window just shows that toolbar and just 
> keeps redrawing it infinitely
I'm not 100% sure I understand, but shadowing your own local display 
does create a sort of nested paint loop. That's expected.

> d) The process that won't die!
> 
> This shadow connection starts another xpra server for :0, and it just 
> WON'T DIE! You can tell it to shutdown via the HTML5 client option, it 
> doesn't shut down, and when you disconnect you will have 2 XPRA 
> processes running, the original :100 and this new :0 process, and sudo 
> kill -9 pid will kill it and then it RESPAWNS... the only way to kill 
> that is to HARD REBOOT the box!
shadow servers don't re-spawn, perhaps it is the proxy server that 
you're killing - this one is managed as a systemd service and will be 
re-spawned.

> e) Password entry issues
> 
> Seems to get things to connect the first time, I have to enter the 
> password twice, even if its saved and auto entered by the browser, and 
> hitting the eye to show it, it is correct, will connect, FAIL 
> VALIDATION, and then enter it again, or let browser fill in again, and 
> 2nd time works. shrug
It isn't clear what command lines / port / (no?)proxy configuration 
triggers this, but I haven't seen this particular problem.

Connections via the proxy do usually require authentication and the 
default is to use system authentication.
After that, the session itself may also require authentication depending 
on how you configured it, but I can't remember if those authentication 
requests can be forwarded through the proxy.

> Comments, insights, welcome... Thanks!

Cheers,
Antoine

> 
> 
> 
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> https://lists.devloop.org.uk/mailman/listinfo/shifter-users