Xpra: Ticket #850: html5 client improvements

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:

And we can always backport pieces later.

Sun, 03 May 2015 14:57:11 GMT - Josh:

sound support is in progress in #845

Wed, 13 May 2015 04:25:05 GMT - Antoine Martin:

See also: #858 (numlock)

Sun, 31 May 2015 08:22:35 GMT - Antoine Martin: attachment set

the connect ui is a bit squashed with firefox

Sun, 31 May 2015 08:22:52 GMT - Antoine Martin: attachment set

the connect ui is a bit squashed with chrome too

Sun, 31 May 2015 08:23:56 GMT - Antoine Martin:

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

the connect ui is a bit squashed with firefox

the connect ui is a bit squashed with chrome too

Sun, 31 May 2015 08:26:20 GMT - Antoine Martin:

Same on MS Windows actually. Another thing which should be to fix: the html5 client is mirrored here: 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.

Sun, 31 May 2015 09:38:54 GMT - 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.

Sun, 31 May 2015 09:42:04 GMT - 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

Mon, 27 Jul 2015 10:53:40 GMT - 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.

Mon, 27 Jul 2015 11:12:45 GMT - 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.

Mon, 27 Jul 2015 11:28:57 GMT - 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!

Sat, 01 Aug 2015 13:02:01 GMT - 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


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.

Sun, 04 Oct 2015 09:50:01 GMT - 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?)

Sun, 04 Oct 2015 19:43:14 GMT - 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.

Mon, 05 Oct 2015 07:08:19 GMT - 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?

echo -n $PASSWORD > password.txt
echo -n $AES_KEY > aes.txt
xpra start :10 --bind-tcp= --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
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

Thu, 15 Oct 2015 12:24:50 GMT - 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...

Thu, 15 Oct 2015 14:16:53 GMT - Antoine Martin: status changed; resolution set

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.

Thu, 15 Oct 2015 16:35:56 GMT - 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 /.

Sat, 23 Jan 2021 05:07:50 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/850