Bug 4132 - Browser client using HTML5/Websockets (Technology Preview)
Summary: Browser client using HTML5/Websockets (Technology Preview)
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: 3.2.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.1.0
Assignee: Peter Åstrand
URL:
Keywords: hean01_tester
Depends on: 4563
Blocks: 4583 4561 4596 4597 4615
  Show dependency treegraph
 
Reported: 2011-12-29 16:00 CET by Peter Åstrand
Modified: 2013-06-24 09:01 CEST (History)
0 users

See Also:
Acceptance Criteria:


Attachments

Comment 3 Peter Åstrand cendio 2012-01-19 11:42:45 CET
Good thing: There's a working HTML5 RDP client:

http://searchvirtualdesktop.techtarget.com/tip/How-long-can-Ericoms-HTML-5-client-dominance-last

Demos available at:
http://www.cloudinternetexplorer.com
http://demo.ericomaccessnow.com

Bad thing:
The demo does not work neither with FF 3.6 on Linux, nor with IE 8 on XP. Not on the EEE Pad with standard browser. This is likely due to the spotty Websockets support: http://en.wikipedia.org/wiki/Websockets

Works with FF on EEE Pad, with FF 9 on XP. Performance is OK. 
Comment 5 Peter Åstrand cendio 2012-01-19 12:57:10 CET
Status of Websockets support:

http://caniuse.com/#search=websockets

I'd say that the Android browser is the only major problem. The fact that you can install other browsers on Android helps somewhat though. 
Comment 8 Peter Åstrand cendio 2012-02-08 08:52:34 CET
Another commercial client:

http://www.remotespark.com/html5.html
Comment 9 Peter Åstrand cendio 2012-02-14 13:35:23 CET
Full screen support might be possible, at least on Safari:

http://stackoverflow.com/questions/3024434/ipad-webapp-full-screen-in-safari
Comment 10 Peter Åstrand cendio 2012-02-14 14:04:51 CET
(In reply to comment #7)

Multiple solutions has been discussed. The consensus is that we should leave SSH out of the picture. Only TLS should be used. Also, I think the architecture should mimic the one used with the Java client and also native clients: that is, have one daemon on every agent, which the client connects to. Thus, the "websocketserver" service would basically have the same purpose as "sshd". 

For the implementation, we could consider reusing parts of the "websockify" server and/or websocket.py. The license is LGPLv3; good for us.
Comment 13 Peter Åstrand cendio 2012-02-22 13:12:33 CET
VMwares stuff:
http://www.youtube.com/watch?v=QBxm5CBPeG8
Comment 14 Peter Åstrand cendio 2012-03-27 08:31:54 CEST
NoMachine are also developing a web client:
http://www.nomachine.com/web-player.php
Comment 18 Peter Åstrand cendio 2012-11-26 16:08:16 CET
According to http://code.google.com/p/android/issues/detail?id=25221:

"It seems Google Chrome for Android is now an official (bundled) browser on Android 4.2+ and it supports WebSockets (verified)."
Comment 19 Peter Åstrand cendio 2012-12-03 14:34:34 CET
We need to decide what should be the Websocket server, and which ports we should use:

1) If we select port 443, we need to find a solution to co-exist with Apache. 
-In practice, co-existing with Apache will probably mean that we must ship either https://github.com/disconnect/apache-websocket or http://code.google.com/p/pywebsocket/, and then integrate the distro Apache with it. 
-Our code would initially execute as the Apache user. If we need to do things as root, that means we need to spawn a setuid binary. 
-Depending on Apache

2) If we select some other port, we need to/can use our own daemon. 
-The default port for encrypted Websocket is port 443, ie the same as TLS. We would use something non-standard. 
-Since we are not using 443, there's a higher risk that we will not get through firewalls etc. 
+The daemon can run as root, just like sshd. 

I've checked some other implementations:

* Novnc uses 6080 by default. 
* Nomachine does not use Websockets, but rather AJAX calls it seems. Uses port 4080. 
* The Ericom Accessnow server uses port 8080 by default, it seems.
Comment 23 Peter Åstrand cendio 2013-04-03 12:09:44 CEST
iOS has some problems with encrypted Websockets, see:

https://github.com/kanaka/noVNC/issues/124
Comment 26 Peter Åstrand cendio 2013-04-17 09:43:33 CEST
When it comes to browser support, we are requiring full WebSocket support, as per RFC 6455. This means:

Internet Explorer 10 or newer
Firefox 11 or newer (all platforms, including Android)
Google Chrome 16 or newer (all platforms, including Android)
Safari 6 or newer (all platforms, including iOS 6)
Opera 12.1 or newer (all platforms)
Please note that the "Android Browser" does not work. 

This list has been compiled using the following resources:
http://code.google.com/p/android/issues/detail?id=25221
http://caniuse.com/#search=websockets
http://en.wikipedia.org/wiki/WebSocket#Browser_support
https://github.com/kanaka/noVNC/wiki/Browser-support
Comment 32 Peter Åstrand cendio 2013-04-23 13:54:07 CEST
The HTML5 will be included in ThinLinc 4.1 as a "Technology Preview" feature.
Comment 35 Peter Åstrand cendio 2013-04-25 09:26:08 CEST
An initial version of the ThinLinc HTML5 Client is now finished.
Comment 36 Henrik Andersson cendio 2013-05-02 13:07:52 CEST
When having a html5 session open (own tlstunnel process) then stopping tlwebaccess service one cant start tlwebacces due to bind failure:

2013-05-02 14:05:35 INFO tlwebaccess[10582]: ThinLinc Web Access version 4.0.0post build 3932 starting...
2013-05-02 14:05:35 INFO tlwebaccess[10582]: ThinLinc Web Access running as PID 10582 on port 300.
2013-05-02 14:05:35 ERROR tlwebaccess[10583]: bind: Address already in use
2013-05-02 14:05:36 ERROR tlwebaccess[10582]: tlstunnel has terminated unexpectedly. Exiting...
Comment 37 Peter Åstrand cendio 2013-05-02 14:23:14 CEST
(In reply to comment #36)
> When having a html5 session open (own tlstunnel process) then stopping
> tlwebaccess service one cant start tlwebacces due to bind failure:
> 
> 2013-05-02 14:05:35 INFO tlwebaccess[10582]: ThinLinc Web Access version
> 4.0.0post build 3932 starting...
> 2013-05-02 14:05:35 INFO tlwebaccess[10582]: ThinLinc Web Access running as PID
> 10582 on port 300.
> 2013-05-02 14:05:35 ERROR tlwebaccess[10583]: bind: Address already in use
> 2013-05-02 14:05:36 ERROR tlwebaccess[10582]: tlstunnel has terminated
> unexpectedly. Exiting...

Fixed in 27293.
Comment 38 Henrik Andersson cendio 2013-05-06 10:48:21 CEST
Upgrading of ThinLinc with active session works, but reconnecting to old sessions fails does to binary Xvnc update.
Comment 39 Peter Åstrand cendio 2013-05-06 10:49:23 CEST
(In reply to comment #38)
> Upgrading of ThinLinc with active session works, but reconnecting to old
> sessions fails does to binary Xvnc update.

Fixed in 27308.
Comment 40 Henrik Andersson cendio 2013-05-07 14:33:55 CEST
Just a note, i have tested the server parts (build 3973) on Ubuntu 12.04, CentOS 6 (selinux) and SLED 11 Sp2 and it does work out of the box, when opening port 300 and starting the service.
Comment 41 Peter Åstrand cendio 2013-05-13 12:55:48 CEST
Need to test: Cluster setup with Chrome browser.
Comment 42 Karl Mikaelsson cendio 2013-05-15 08:44:12 CEST
Brief test with a Chromebook (with Chrome 26) shows satisfactory results - nothing obviously broken. (this comment was written with the html5 client from the demo system).
Comment 43 Henrik Andersson cendio 2013-05-20 09:23:19 CEST
(In reply to comment #41)
> Need to test: Cluster setup with Chrome browser.

At a customers site which running RHEL 6 (2 masters and 2 agents) in their cluster there is a problem using chrome browser which fails to connect with:
Failed to connect to server (code: 1008, reason: Missing session key)

On ThinLinc side, everything is ok, session is created etc.
Comment 44 Henrik Andersson cendio 2013-05-20 09:24:21 CEST
(In reply to comment #43)
> (In reply to comment #41)
> > Need to test: Cluster setup with Chrome browser.
> 
> At a customers site which running RHEL 6 (2 masters and 2 agents) in their
> cluster there is a problem using chrome browser which fails to connect with:
> Failed to connect to server (code: 1008, reason: Missing session key)
> 
> On ThinLinc side, everything is ok, session is created etc.

This seems to affect firefox too, now when testing it from office, however firefox worked when i tested it on site.. :/
Comment 45 Henrik Andersson cendio 2013-05-20 12:14:21 CEST
(In reply to comment #44)
> (In reply to comment #43)
> > (In reply to comment #41)
> > > Need to test: Cluster setup with Chrome browser.
> > 
> > At a customers site which running RHEL 6 (2 masters and 2 agents) in their
> > cluster there is a problem using chrome browser which fails to connect with:
> > Failed to connect to server (code: 1008, reason: Missing session key)
> > 
> > On ThinLinc side, everything is ok, session is created etc.
> 
> This seems to affect firefox too, now when testing it from office, however
> firefox worked when i tested it on site.. :/

This was due to eraseCookie() was commented out at customers site and both browsers had old cookies.
Comment 46 Henrik Andersson cendio 2013-05-21 09:07:29 CEST
When entering wrong password, there are 2 error messages displayed which clutters the ui and probably will confuse some users:

- No response from PAM subsystem

- Authentication failure

The last one should be good enough.
Comment 47 Peter Åstrand cendio 2013-05-21 09:21:31 CEST
(In reply to comment #46)
> When entering wrong password, there are 2 error messages displayed which
> clutters the ui and probably will confuse some users:
> 
> - No response from PAM subsystem
> 
> - Authentication failure
> 
> The last one should be good enough.

Fixed in 27417.
Comment 49 Henrik Andersson cendio 2013-05-24 11:22:33 CEST
I have now tested the HTML5 client build 3960 using iPad.

Setting config key /vsmagent/default_geometry to 1024x680 make the view
fit the display perfectly on iPad, no need to pan around on desktop.

I created a cert for my server name and downloaded cert for installation without any problems. Created a desktop link to the Html5 client WebApp and logged on without any problems.

Tested the toolbar buttons and the clipboard functionlity which works as expected.

When disconnecting while in WebApp mode I think one might want to get back to iOS desktop instead of showing a vnc disconnected message.
Comment 50 Henrik Andersson cendio 2013-05-24 12:41:33 CEST
There is a strange error message when writing the wrong password, could this be a little more end-user friendly?

"Failure setting user credentials"
Comment 51 Henrik Andersson cendio 2013-05-27 07:41:49 CEST
I left a browser window with an active session open over the weekend, and it works as expected after 2.5 days, not hangs nor disconnect.
Comment 52 Peter Åstrand cendio 2013-05-27 09:59:48 CEST
(In reply to comment #50)
> There is a strange error message when writing the wrong password, could this be
> a little more end-user friendly?
> 
> "Failure setting user credentials"

Fixed in 27448.
Comment 53 Henrik Andersson cendio 2013-05-28 12:44:47 CEST
I have tested the html5 client in both single master/agent and clustered thinlinc setups and it works good with several authentication mechanisms, local, active directory and one time password without any problems. A lot of issues has been noticed, fixed or postponed into corresponding bugs. It does work well except several issues with keyboard inputs depending on browers/platforms but there is an upcoming rewrite of keyboard handling upstream so those issue are ignored for now.
Comment 54 Henrik Andersson cendio 2013-05-31 10:27:52 CEST
It is possible to have both native client and html5 client connecting and viewing the same session without using shadowing.

Reproducable by:

Login and create a session with html5 client while logged on, start a native client and log in.
Comment 55 Henrik Andersson cendio 2013-05-31 10:38:20 CEST
(In reply to comment #54)
> It is possible to have both native client and html5 client connecting and
> viewing the same session without using shadowing.
> 
> Reproducable by:
> 
> Login and create a session with html5 client while logged on, start a native
> client and log in.

This issue is related to bug #2251 due to there are no resources redirections available in the HTML5 client.
Comment 56 Peter Åstrand cendio 2013-06-10 11:55:25 CEST
The current code does not handle Cookie headers with multiple cookies separated by semicolon. From http://tools.ietf.org/html/rfc6265#section-4.2.1:

4.2.1. Syntax

   cookie-header = "Cookie:" OWS cookie-string OWS
   cookie-string = cookie-pair *( ";" SP cookie-pair )

Currently, we are only parsing the first cookie-pair.
Comment 57 Peter Åstrand cendio 2013-06-10 13:44:08 CEST
(In reply to comment #56)
> The current code does not handle Cookie headers with multiple cookies separated
> by semicolon. From http://tools.ietf.org/html/rfc6265#section-4.2.1:
> 
> 4.2.1. Syntax
> 
>    cookie-header = "Cookie:" OWS cookie-string OWS
>    cookie-string = cookie-pair *( ";" SP cookie-pair )
> 
> Currently, we are only parsing the first cookie-pair.

Fixed in 27497.
Comment 58 Pierre Ossman cendio 2013-06-10 14:50:43 CEST
Installation fails on Solaris:

2013-06-10 14:45:21,238: Packages to upgrade: CENDthinlinctlmisc-4.1.0-3977-sparc, CENDthinlinctlmisclibs-4.1.0-3977-sparc, CENDthinlincvsm-4.1.0-3977-sparc, CENDthinlincvncserver-4.1.0-3977-sparc, CENDthinlincr
desktop-4.1.0-3977-sparc, CENDthinlinctladm-4.1.0-3977-sparc, CENDthinlinctlprinter-4.1.0-3977-noarch, CENDthinlincwebaccess-4.1.0-3977-noarch
2013-06-10 14:45:28,304: Removing installed package(s): CENDthinlinctlmisc, CENDthinlinctlmisclibs, CENDthinlincvsm, CENDthinlincvncserver, CENDthinlincrdesktop, CENDthinlinctladm, CENDthinlinctlprinter, CENDthi
nlincwebaccess
2013-06-10 14:46:15,335: Installing package(s): CENDthinlinctlmisc-4.1.0-3977-sparc, CENDthinlinctlmisclibs-4.1.0-3977-sparc, CENDthinlincvsm-4.1.0-3977-sparc, CENDthinlincvncserver-4.1.0-3977-sparc, CENDthinlin
crdesktop-4.1.0-3977-sparc, CENDthinlinctladm-4.1.0-3977-sparc, CENDthinlinctlprinter-4.1.0-3977-noarch, CENDthinlincwebaccess-4.1.0-3977-noarch
2013-06-10 14:46:25,686: Installation of package failed:
2013-06-10 14:46:25,687:     /var/sadm/pkg/CENDthinlincwebaccess/install/postinstall: PATH=/sbin:/usr/sbin:/usr/bin:/usr/sadm/install/bin:/opt/thinlinc/share/xdg-utils: is not an identifier
2013-06-10 14:46:25,688:     pkgadd: ERROR: postinstall script did not complete successfully
2013-06-10 14:46:25,688:     
2013-06-10 14:46:25,688:     Installation of <CENDthinlincwebaccess> failed.
Comment 59 Peter Åstrand cendio 2013-06-11 13:08:59 CEST
(In reply to comment #58)
> Installation fails on Solaris:

Should be fixed in r27506.
Comment 60 Aaron Sowry cendio 2013-06-12 14:12:50 CEST
The move of Cheetah from tladm to tlmisc in r26470 breaks upgrades, at least on .deb systems.

2013-06-12 04:24:04,898: Warning during installation of '/home/aaron/tl-4.1.0-server/serverkit-linux/thinlinc-tlmisc_4.1.0-3974_i386.deb': " trying to overwrite '/opt/thinlinc/modules/Cheetah/convertTmplPathToModuleName.py', which is also in package thinlinc-tladm 4.0.0-3717"

This leaves the packages in a strange state, where everything else is upgraded but tlmisc remains at v4.0.0.
Comment 61 Pierre Ossman cendio 2013-06-13 11:01:06 CEST
Fixed in r27516.
Comment 62 Henrik Andersson cendio 2013-06-24 09:01:36 CEST
(In reply to comment #60)
> The move of Cheetah from tladm to tlmisc in r26470 breaks upgrades, at least on
> .deb systems.
> 
> 2013-06-12 04:24:04,898: Warning during installation of
> '/home/aaron/tl-4.1.0-server/serverkit-linux/thinlinc-tlmisc_4.1.0-3974_i386.deb':
> " trying to overwrite
> '/opt/thinlinc/modules/Cheetah/convertTmplPathToModuleName.py', which is also
> in package thinlinc-tladm 4.0.0-3717"
> 
> This leaves the packages in a strange state, where everything else is upgraded
> but tlmisc remains at v4.0.0.

This was verified on bug #4443 comment #5

Note You need to log in before you can comment on or make changes to this bug.