This schema works well in most cases. Nevertheless, there are situations where something less restrictive, requiring less administration work seems to be more appropriate. There are at least two typical situations:
This document describes how to configure the W2H interface to be able to use it in the intranet mode. It requires only very little configuration in Cfg.pl file and nowhere else. Nevertheless, you can easily include your own CGI scripts to start and to finish a session to provide your own look-and-feel.
Table of Contents
$INTRANET = 'yes';By the way, all variables mentioned above and below have to be set in the configuration file Cfg.pl.
By default, the intranet mode is not set. But all other intranet variables are distributed with reasonable values which allow you to try this mode. The only change you must do is to set $INTRANET to yes.
Second, you must tell where the users data file are to be put (remember that the users have no home directories on the server computer). This is done in the variable $USERS_DIR:
$USERS_DIR = '/tmp';The variable should contain a directory name which is writable for the user running the httpd server (or better: for the user whose name is specified in the User directive in the httpd configuration file). A special subdirectory _W2H_ will be automatically created here containing the individual directories for all connected users.
A distributed default for $USERS_DIR is $TMPDIR which is set to /tmp.
And finally, there are three main questions to be answered to run the W2H in the intranet mode:
The variable $USER_ID deals with the user identification.
There are several methods to choose from:
This default identification page asks for a user name. The users can type
any name they like. If you are not happy with this behavior, you
can write your own identification script to restrict it. Take the script
w2h.intra-userid as a template and help yourself to comments written
there. Then put a full UNIX path of your script into the
$USER_ID variable.
Two more notes. First, what you put into $USER_ID variable must be
an executable. It is important because it distinguishes this
method from the other one described below (the other one uses the same
variable but puts there a name of a plain non-runnable file).
Second, the default script w2h.intra-userid can generate and show also
a list of possible users where a user name can be chosen from. If you like
this feature, put the users list into a variable $USERS. For example:
Automatic names generating does not mean that every time a
user gets a new name. The name is generated only if it is not yet known.
So even with your name automatically generated, you can still access your
personal setting and/or your data each time you connect to the GCG server.
How to keep this information and for how long, it is described in the
following sections about keeping state and cleaning session.
The data files created by the GCG programs are safely stored in your own data space
during your GCG session. But whether they remain untouched also after you
exit your GCG session it does not depend on the variable $KEEP_STATE
but on an another one ($CLEAN_SESSION) described in the section below.
The $KEEP_STATE concerns about your global settings, such as your default
printer. Sure, it also stores information about your current working directory
and your current working list. But if you let them clean up after exiting the
GCG session then this information becomes a little useless.
Now back to the available options:
Fill the variable $KEEP_STATE with a script name (again full UNIX
path please) which will be called at the end of a session:
And even more. w2h.intra-save stores also the contents of the last
used working list. The W2H will try to re-created it at the beginning of the
next session if it does not exist any more.
Note that this option usually does not remove data of the user whose GCG
session has just finished because his/her data are very likely too new to be
deleted.
If you set it to yes or true users will be allowed to change their
current working directory and put their data to a new place. It can be reasonable
option but remember that session cleaning described in the previous chapter deals
only with data in the standard working directory based on $USERS_DIR
variable. New data space will not be cleaned up.
A default value is no or false or an empty string. Then the button
Change working directory in the Main Window is disabled. But be aware that
the intranet mode is not too keen to restrict users: even if they cannot change to
a new working directory, they are allowed to create working lists or
data output files somewhere else (if UNIX access rights allow it).
This behavior can be changed in the future if need will arise.
If you do not use firewall but want to try or use the W2H in the intranet mode you
would probably like to avoid an access of completely foreign users to your server
(at least because GCG is a proprietary software). It can be reached by using the
HTTP authentication method in less restrictive way allowing an access only from
your network domain.
Here is an example what to add to your access.conf file if you want to allow
accesses only from your domain (put there your domain name):
User identification
From the UNIX point of view, all programs on the server side are run under the
user specified in the User (or similar) directive in an httpd configuration file.
But it is not enough for the intranet mode. We want to keep separately the data
and setting of the individual GCG users even if all of them appear to be the same UNIX user.
Even without the UNIX accounts and UNIX password files on the server side,
you have still a possibility to use a standard HTTP authentication procedure.
Do it in the same way as with a normal W2H installation. Let me quote from the
installation chapter:
The directory w2h with CGI scripts must be accessible only after user's
authentication. To do it, edit the server configuration file access.conf,
or create a special file .htaccess in the directory w2h, depending
on the policy you are using on your server.
After having that, just set the variable $USER_ID to
an empty string (or remove it at all):
$USER_ID='';
If you do not use an HTTP authentication method for the user identification
you must present to your users a different form where they can identify themselves.
The simplest way to do it is to use a script w2h.intra-userid coming
with the W2H distribution. The variable $USER_ID should be like this:
$USER_ID = "$YA_ROOT/w2h.intra-userid";
By the way, this is a distributed default in Cfg.pl.
$USERS = 'Juha, Thanaradz, Tim, Chris, J&J, Alan, Martin';
You can also put here a file name (full UNIX path please) with user names.
Each line of the file should contain a single user name. But everything after
colon (if present) is ignored so you can use here /etc/passwd if it
suits you. An example:
$USERS = '/www/w2h/users';
In some situations, for example during a conference demo, you do not care
about user names. So let them generate automatically and randomly! Just put a file
name with all possible user names into the variable $USER_ID:
$USER_ID = '/usr/share/lib/dict/words';
In this example you will get the nice user names from the standard
UNIX spelling dictionary.
Keeping user's session setting
How to remember the current user's setting after finishing a GCG session?
The variable $KEEP_STATE deals with it. Again, you have several options
to choose from. But before describing them in details let me explain what is
not kept.
Set the variable $KEEP_STATE to an empty string if you wish to
forget everything about a GCG session after exiting the current Netscape:
$KEEP_STATE = '';
Set the variable $KEEP_STATE to no or false
if you wish to
forget everything about a GCG session immediately when you exit it,
still within the current Netscape:
$KEEP_STATE = 'no';
Both options may be useful for training courses or hands-on workshops.
But not very exciting.
Using this option, a user when exits a GCG session will be presented by an HTML page
advising him/her to save this page on his/her local computer. The page
contains all kept information and a button Restart GCG session.
Clicking on the button revives all stored session setting, and starts a new
session.
$KEEP_STATE = "$YA_ROOT/w2h.intra-save";
The default distribution of the W2H uses a script w2h.intra-save
which can again serve as a template for your own company-suited script (or
even a static HTML page). This default script not only stores the information
but let users to change it before starting a new GCG session.
In fact, this option stores the information on your local computer as well.
But it uses a special Netscape feature which makes the usage more transparent.
(But also less powerful l: the last used working list is not stored, so it cannot
be automatically re-created.).
A small quotation and a reference FYI:
Cookies are a general mechanism which server side connections (such as CGI scripts) can
use to both store and retrieve information on the client side of the connection. The addition of a
simple, persistent, client-side state significantly extends the capabilities of Web-based
client/server applications.
Put into the variable $KEEP_STATE a number of days (fractions are
allowed) how long you would like to keep the user's setting saved. For example:
http://home.netscape.com/newsref/std/cookie_spec.html
$KEEP_STATE = '10';
This will let the users to start within 10 days and to use the same global
options as in the previous GCG session.
Cleaning session data
During a GCG session the users create data files on the GCG server computer. Within
a current session they can view them or re-use them again and again. But what to
do with them when the session is over? In the non-intranet mode it is up to the users
to take care about their home directories (and also up to the programs like
quota I must admit). In the intranet mode there is a variable
$CLEAN_SESSION with several possible options:
Put here an empty string to avoid any cleaning:
$CLEAN_SESSION = '';
An exactly opposite alternative. All user's data will be removed when a GCG session
exits. Put here yes or true:
$CLEAN_SESSION = 'yes';
This is not so bad as it may sound. Remember that all user's personal
global options, even his/her last working list can be saved locally using a
proper option in $KEEP_STATE variable (see above).
This option is different from the previous ones because it deals with data
files of all users. Each time when a GCG session ends it checks all
directories specified in $USERS_DIR variable, and remove those
directories in which the newest file is older than the number of days specified
in $CLEAN_SESSION variable. So it is a sort of automatic cleaning
when data are not used long enough. An example:
$CLEAN_SESSION = '30';
The data file of all users who have not updated their files within last month
will be deleted in a moment when any GCG session finishes. Sure, only
files in $USERS_DIR space are touched.
Working directory
There is one more variable to configure: $CHANGE_WD_ALLOWED.
But it seems to be less important than the others.
Security consideration
The intranet mode is not less secure than the standard one. But it differs in a fact who is
responsible for security. In a standard mode it is a basic HTTP authentication method,
and in the intranet mode it is someone else. Often it is a firewall software. But as was
shown above you can still use the HTTP authentication procedure in the intranet mode.
<Directory /usr/local/etc/httpd/cgi-bin/w2h>
Or you can configure the same thing using a .htaccess file in the directory w2h:
Options Indexes FollowSymLinks
<Limit GET POST>
order deny,allow
deny from all
allow from .ebi.ac.uk
</Limit>
</Directory>
<Limit GET POST>
More about the access configuration can be found at
http://hoohoo.ncsa.uiuc.edu/.
order deny,allow
deny from all
allow from .ebi.ac.uk
</Limit>
Last modified: Thu Dec 28 18:00:56 2000