www.cendio.com
Bug 4132 - Browser client using HTML5/Websockets (Technology Preview)
: Browser client using HTML5/Websockets (Technology Preview)
Status: CLOSED FIXED
: ThinLinc
Web Access
: 3.2.0
: PC Unknown
: P2 Normal
: 4.1.0
Assigned To:
:
:
: 4563
: 4561 4583 4596 4597 4615
  Show dependency treegraph
 
Reported: 2011-12-29 16:00 by
Modified: 2013-06-24 09:01 (History)
Acceptance Criteria:


Attachments


Note

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


------- Comment #3 From cendio 2012-01-19 11:42:45 -------
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 From cendio 2012-01-19 12:57:10 -------
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 From cendio 2012-02-08 08:52:34 -------
Another commercial client:

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

http://stackoverflow.com/questions/3024434/ipad-webapp-full-screen-in-safari
------- Comment #10 From cendio 2012-02-14 14:04:51 -------
(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 From cendio 2012-02-22 13:12:33 -------
VMwares stuff:
http://www.youtube.com/watch?v=QBxm5CBPeG8
------- Comment #14 From cendio 2012-03-27 08:31:54 -------
NoMachine are also developing a web client:
http://www.nomachine.com/web-player.php
------- Comment #18 From cendio 2012-11-26 16:08:16 -------
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 From cendio 2012-12-03 14:34:34 -------
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 From cendio 2013-04-03 12:09:44 -------
iOS has some problems with encrypted Websockets, see:

https://github.com/kanaka/noVNC/issues/124
------- Comment #26 From cendio 2013-04-17 09:43:33 -------
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 From cendio 2013-04-23 13:54:07 -------
The HTML5 will be included in ThinLinc 4.1 as a "Technology Preview" feature.
------- Comment #35 From cendio 2013-04-25 09:26:08 -------
An initial version of the ThinLinc HTML5 Client is now finished.
------- Comment #36 From cendio 2013-05-02 13:07:52 -------
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 From cendio 2013-05-02 14:23:14 -------
(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 From cendio 2013-05-06 10:48:21 -------
Upgrading of ThinLinc with active session works, but reconnecting to old
sessions fails does to binary Xvnc update.
------- Comment #39 From cendio 2013-05-06 10:49:23 -------
(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 From cendio 2013-05-07 14:33:55 -------
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 From cendio 2013-05-13 12:55:48 -------
Need to test: Cluster setup with Chrome browser.
------- Comment #42 From cendio 2013-05-15 08:44:12 -------
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 From cendio 2013-05-20 09:23:19 -------
(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 From cendio 2013-05-20 09:24:21 -------
(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 From cendio 2013-05-20 12:14:21 -------
(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 From cendio 2013-05-21 09:07:29 -------
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 From cendio 2013-05-21 09:21:31 -------
(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 From cendio 2013-05-24 11:22:33 -------
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 From cendio 2013-05-24 12:41:33 -------
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 From cendio 2013-05-27 07:41:49 -------
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 From cendio 2013-05-27 09:59:48 -------
(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 From cendio 2013-05-28 12:44:47 -------
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 From cendio 2013-05-31 10:27:52 -------
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 From cendio 2013-05-31 10:38:20 -------
(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 From cendio 2013-06-10 11:55:25 -------
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 From cendio 2013-06-10 13:44:08 -------
(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 From cendio 2013-06-10 14:50:43 -------
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 From cendio 2013-06-11 13:08:59 -------
(In reply to comment #58)
> Installation fails on Solaris:

Should be fixed in r27506.
------- Comment #60 From cendio 2013-06-12 14:12:50 -------
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 From cendio 2013-06-13 11:01:06 -------
Fixed in r27516.
------- Comment #62 From cendio 2013-06-24 09:01:36 -------
(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