I'm about to release version 1.7 of httpvnc. So what's new?
User supplied names for desktop sessions
Desktop sessions now have a user supplied name. This name can be specified when creating a desktop (can't be edited after that, for now). This makes it easier for a user to manage multiple running desktops.
Furthermore, together with the new command line interface, this allows to avoid desktop "clones", because the 'create' command will only create a new desktop if there is no desktop available already with that specific name for that specific user. This is a very useful feature, and I will later post a blog entry explaining how to replace Java applets by httpvnc panes in a Tomcat driven e-learning platform using this particular feature.
CLI interface for "Onetime" sessions
httpvnc now allows to create, destroy and list desktop sessions on the command line. This feature is intended for sites where user authentication and management is done by some other software than httpvnc, e.g. some Tomcat instance that will create desktops as needed for one or more users and just use the httpvnc webserver in order to display the desktops.
Onetime IDs and scrambled IDs
This was one of the most pressing matters. Until recently, httpvnc security could be breached by simply harvesting session IDs from the running browser or even the browser cache, because websocket streams were not authenticated. It was then no problem at all to simply reconnect using these IDs, and if a desktop session was still running, the attacker could connect to it without any further authentication.
Websockets still aren't authenticated, but IDs are now scrambled so that the IDs you can read in the HTML source code of the desktop pages are in fact useless for replay attacks, because they are valid only for a very short period of time, usually enough for an authenticated connect; after that, they quickly perish.
A related feature are Onetime IDs; these can be generated from the command line (by an administration task, not by the users themselves). Onetime IDs can be used once only to connect (without any further authentication) to a running desktop; after that, they are worthless. There is a special URL for Onetime ids. It is obvious that whatever mechanism will provide users with Onetime IDs, will have to do some sort of authentication and access control, too. However, how this is done is up to this mechanism.
Different fvwm configuration files choosable
Users may now choose different fvwm configuration files for their desktops. For now, this can only be done in the CLI interface. I will post an updated version of the web interface later that supports this, too.
Again, this is a very handy feature, and it will also play a role in the Java applet replacement scenario I mentioned earlier.
fvwm configuration files are searched by fvwm in the standard places, e.g. /usr/share/fvwm and ~/.fvwm