termlib.js home | multiple terminals | parser | faq | documentation | samples
> open terminal 
remote terminal sample
(c) mass:werk,
N. Landsteiner 2005-2007

termlib.js Remote Terminal Sample

This is a simple example for a remote terminal client using termlib.js.

Be sure to understand why NOT to use this for real!

The Client Part

For the client-side part see the source code of this page:

Userid and password are transfered in plain text in the post body of each request. Also userid and password are stored in instance properties of the Terminal object. (Use the local command "rlogout" to clear those.)
For minimum security username and password settings are not stored in the script but must be checked on the server side.

When logged in, the terminal echoes any output of the shell as it executes the command(s) at the remote host. Have a look at the Perl script below for an example of how to capture both STDOUT and STDERR of a command.

You will NOT be able to edit any file at the remote host! For this you would need a true interactive terminal client. (A work-around could be the implementation of a vi-like editor inside the terminal or an export/import facillity for external editing. So you could fetch a file, edit it in the browser, and transfer it back to the remote host.) For the same reason you won't be able to execute any interactive commands (e.g. "su").

Be sure to understand that this does NOT open an interactive session.
The location of the current working directory is transfered forth and back between host and client. This enables some real shell-like behavior, but it is essential to understand that each line of command(s) is executed separately at the remote host in a shell session of its own.

Userid and password are only provided for (a very weak) secutity. The commands will execute with the UID and GID of the server-side CGI-script.

As all client-server transfers are performed via XMLHttpRequests, you may only connect to the originating host of the served page.

Please mind that there is no guarantee for the correctness of the displayed or transfered data.
The termlib.js interface should work reliably with the printable characters of the US-ASCII charset (but mind that it is provided "as is"). Be sure to understand the risks of charset-translations (as might be involved client-side as well as server-side with any interface of this kind) and the immanent risk of damage and/or loss of data.


The Server Part

This is a simple Perl script as an example for a server-side interface.
We'll assume the host is UINIX-style and addressed via the Common Gateway Interface of the web-server (e.g. Apache). As above, be sure to understand why NOT to use this for real.


### termbackend.pl                                           ###
### sample backend for the termlib.js remote terminal sample ###
### example only, do not use for real!                       ###

use strict;
use CGI;
use IPC::Open3;
use Symbol qw(gensym);

#### username and password here

my $userid = 'user';
my $password = 'password';

#### get cgi params

my $q = new CGI;
my $user = $q->param('user');
my $pass = $q->param('pass');
my $cmd = $q->param('command') || '';
my $dir = $q->param('dir') || $ENV{DOCUMENT_ROOT};

#### start output

print "Content-type: text/plain\n\n";

if (($user eq $userid) && ($pass eq $password)) {
    # passed user authorization

    # prepare the command string:
    # first append echo of working dir as last line
    # and clean up the command string (leading blanks etc)

    $cmd .= ';echo "";echo "dir:$PWD"';
    $cmd =~ s/^[\\;\s]+//;

    # change dir and return command output ...

    chdir($dir) || die "Error: Could not change directory.";

    # simple backticks (print `$cmd`) won't catch STDERR
    # so we'll use open3 and mix STDOUT and STDERR ...

    my $pid = open3(gensym, \*CATCH, \*CATCH, $cmd);
    while( <CATCH> ) {
       print $_;
    waitpid($pid, 0);
else {
    # authorization failed, return Sorry.
    print "Sorry.";

### eof


A script like this must be installed on your web-server (probably in the cgi-bin directory) with sufficient execute permissions in order to make this sample work. Since this is not installed on the mass:werk server, this page won't be functional on this site.

Be sure to understand that installing a script like this on a public server will mean to welcome hackers with open doors ...


This piece of software is published as an example only and AS IS. No warranty of any kind is granted, not even the implied warranty of fitness for a particular purpose. You are advised to NOT use this script for real. Be aware that using this script or any interface alike bears the risk of serious damage and loss of data. Be also aware that there is no guarantee of any kind for the correctness of the data displayed or transfered.