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.
sound support is in progress in #845
See also: #858 (numlock)
the connect ui is a bit squashed with firefox
the connect ui is a bit squashed with chrome too
I think the CSS needs tweaking, here's how the encoding drop down looks on Linux:
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.
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.
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
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.
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.
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!
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.
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?)
@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.
@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
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...
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.
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 /
.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/850