xpra icon
Bug tracker and wiki

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#850 closed task (fixed)

html5 client improvements

Reported by: Antoine Martin Owned by: Josh
Priority: major Milestone: 0.16
Component: html5 Version: trunk
Keywords: Cc:

Description

Split from #473. Mostly things that didn't make the cut for the v0.15 release.
Feel free to add more to this list.

Here are a few (that may or may not still be applicable) that I have noticed:

  • sound support
  • some focus problems: when my xterm window shows up, it doesn't always get focus, despite clicking on it!?
  • it is possible for the html client to say "connection closed" because of a timeout, but it will still accept a "hello" packet that arrives after that (I saw that whilst testing for #838 - maybe debug mode related)
  • cursor forwarding? (probably very hard - css expect a url.. and we don't want to start writing cursors to disk)
  • desktop-size change messages: probably just log it and ignore rather than warn?
  • some of the more obscure ewmh calls #773 / #775 (ie: #772 for chrome)

And we can always backport pieces later.

Attachments (2)

html5-squashed-ui-on-firefoxlinux.png (19.9 KB) - added by Antoine Martin 2 years ago.
the connect ui is a bit squashed with firefox
html5-squashed-ui-on-chromelinux.png (26.2 KB) - added by Antoine Martin 2 years ago.
the connect ui is a bit squashed with chrome too

Download all attachments as: .zip

Change History (18)

comment:1 Changed 2 years ago by Josh

sound support is in progress in #845

comment:2 Changed 2 years ago by Antoine Martin

See also: #858 (numlock)

Changed 2 years ago by Antoine Martin

the connect ui is a bit squashed with firefox

Changed 2 years ago by Antoine Martin

the connect ui is a bit squashed with chrome too

comment:3 Changed 2 years ago by Antoine Martin

I think the CSS needs tweaking, here's how the encoding drop down looks on Linux:

  • Firefox:

the connect ui is a bit squashed with firefox

  • Chrome:

the connect ui is a bit squashed with chrome too

comment:4 Changed 2 years ago by Antoine Martin

Same on MS Windows actually.
Another thing which should be to fix: the html5 client is mirrored here: http://xpra.org/html5/ - problem is that when you hit this URL, it tries to auto-connect, fails, then redirects to http://xpra.org/connect.html instead of http://xpra.org/html5/connect.html. The URL should be relative I think.

PS: I've added symlinks so now you don't end up with 404.

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:5 Changed 2 years ago by Josh

r9559 fixes the relative URL redirect for the connect.html

r9560 adjusts the layout of the connect.html interface slightly - the controls were specified as being inline on a single line but the width constraint caused them to bunch up like that. Not sure why the text is clipping in the drop down box - it wasn't doing this before - so removed the styling for now.

comment:6 Changed 2 years ago by Antoine Martin

Thanks (that was fast!)

FYI: I've created a wiki page for the HTML5 client to make it easier for people to get started: wiki/Clients/HTML5

comment:7 Changed 2 years ago by Josh

r10073 adds support for password authentication. You can supply username and password via URL parameters but unless the page is served from HTTPS these will be sent in clear text!

Still thinking of the best way to add this into the connect.html UI without leaking the credentials in the address bar.

comment:8 Changed 2 years ago by Josh

it is possible for the html client to say "connection closed" because of a timeout, but it will still accept a "hello" packet that arrives after that (I saw that whilst testing for #838 - maybe debug mode related)

r10074 makes sure that we only call the connection closed callback once, when the connection has really closed and with the correct reason.

comment:9 Changed 2 years ago by Antoine Martin

Still thinking of the best way to add this into the connect.html UI without leaking the credentials in the address bar.


This is probably a silly suggestion, but I thought doing an http POST was the standard way of dealing with this issue.

As for the rest: ACK, good stuff!

comment:10 Changed 2 years ago by Josh

POST is the best way but the server built in to websockify does not support this method. Looking like I might have to patch websockify.

With #933 we can now support AES encryption as of r10204 in the HTML5 client.

To enable encryption, use URL arguments like

?encryption=AES&key=asdfjkl&password=asdfjkl&/

watch out incase your browser adds a trailing /. This won't work on older servers that do the "space byte padding", i.e. pre r10183.

It was already possible to use TLS-encrypted websocket (wss://) but this requires extra setup on the server for the certificates. It also only encrypts communication between the browser and the websockify proxy. However, if these two things are acceptable it will probably have better performance than doing AES in Javascript.

comment:11 Changed 2 years ago by Antoine Martin

I have added html authentication to the wiki, see wiki/Clients/HTML5.
It would be nice if there was a username + password box in the GUI under "advanced" options.

As for AES, I couldn't get it to work. All I did was to add --encryption=AES --encryption-keyfile=./aes.key then append key=THEKEYVALUE to the URL.
@joshiggins: what's the trick I am missing? (and what's the best way to debug such problems?)

comment:12 Changed 2 years ago by Josh

@antoine: You need encryption=AES&key=THEKEYVALUE in the URL, not sure if you missed that off when you tested or when you added the comment ;) I can't remember checking encryption without password auth also enabled.... does it work for you with both AES & password auth?

For the username and password box, because we are using the debugging server built into websockify for serving the page, it does not support POST request (which means we will leak the password in the URL which probably is not acceptable). They also rejected my proposal upstream to add this support . This might need a more creative solution such as prompting for password from the main client page (not connect.html) or using our own http server.

comment:13 Changed 2 years ago by Antoine Martin

@joshiggins: yes, I did have the extra URL arguments, sorry about that.

Here's what I am trying, what am I doing wrong? And how would I debug this?

PASSWORD=123456
AES_KEY=0123456789ABCDEF
echo -n $PASSWORD > password.txt
echo -n $AES_KEY > aes.txt
xpra start :10 --bind-tcp=0.0.0.0:10000 --start-child=xterm \
    --password-file=password.txt --auth=file \
    --encryption-keyfile=./aes.txt --encryption=AES \
    --html=on -d auth
sleep 5
xdg-open "http://localhost:10000/index.html?username=$USER&password=$PASSWORD&encryption=AES&key=$AES_KEY"

You should be able to cut&paste this command block and just run it as-is.

The browser is doing something then just goes to the index page.

The server log does not show anything useful either:

New tcp connection received from 127.0.0.1:46367
creating authenticator <class 'xpra.server.auth.file_auth.Authenticator'>
loaded auth data from file /home/antoine/projects/Xpra/trunk/src/password.txt: {'': ('123456', 1000, 1000, [':10'], {}, {})}
sending data using AES encryption
receiving data using AES encryption
server cipher={'cipher.key_salt': '0bb41220a5104c2e89cfb5e46b0b277b7e6de93098f547d98c0ef4cf0b93e4e7', 'cipher.padding': 'PKCS#7', 'cipher.padding.options': ['PKCS#7', 'legacy'], 'cipher.key_stretch_iterations': 1000, 'cipher.iv': 'eace735ea334456d', 'cipher': 'AES'}
processing authentication with Password File Authenticator, response=None, client_salt=
Authentication required, Password File Authenticator sending challenge for 'antoine' using digest hmac
Connection lost

comment:14 Changed 2 years ago by Josh

r10847 makes retrieving the URL parameters more robust because the trailing slash is causing no end of weird problems.

RE debugging: the best way is to add &debug=true to the URL. I ran your command block with this and I get the message

error processing packet TypeError: Cannot read property '0' of null

which means we failed to decrypt the packet, probably because our key is wrong. This should throw a more friendly error.

In my testing up to now I used the same file for the --password-file and --encryption-keyfile options. Out of curiosity, in the URL I changed the key so that it is the same as the password (123456) and it started decrypting the packets properly!


Unless I did something wrong in the HTML5 client, it looks like with both --password-file and --encryption-keyfile the Xpra server is using the password to generate the AES secret (the default behaviour prior to v0.11) even if we specify an alternate key file...

comment:15 Changed 2 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

Right, I was seeing the same thing today. This mess is caused by the legacy password compatibility code: we have tcp-encryption and tcp-encryption-keyfile, as well as encryption and encryption-keyfile... and there is some validation code for those too, but in order to support legacy mode, it doesn't fire. I will remove this mess in 0.17. For the time being, the logging has been improved to show where we get the key from (r10848 and r10850).

The fallback code uses the password file if no key file is supplied, which explains why it worked when you used the same value!

I have updated the wiki with the correct information: wiki/Clients/HTML5.

I think we can close this ticket for 0.16, there is lots of new stuff already.

comment:16 Changed 2 years ago by alas

Just a quick note about the issue with the trailing / added by browsers in many cases (comment:10) - I noticed that if I added a trailing & to the url string then the final value didn't try to process with the appended /.

Note: See TracTickets for help on using tickets.