The WN server allows you to give users on the server their own private hierarchy for their home page and accompanying documents. The URL for a document in such a hierarchy contains a special string (which the maintainer may choose) to indicate that an alternate hierarchy is being used. There are three more or less mutually exclusive methods in WN to do this. One uses user names and consults the system password file to calculate a "home page" directory in the appropriate user's home directory. The second uses a table lookup to change the server root directory to one specified by the maintainer. Both of these set the data hierarchy based on information in the URL. A third method can be used on systems which support multiple IP interfaces on a single host and will use a different data root for different IP addresses by which the server is accessed.
A common idiom on the Web is to use a URL like
"http://hostname/~john/foo.html" to request a document in a
subdirectory of the home directory of user "john".
WN implements this using the first of the mechanisms above.
The maintainer uses the macro #define TILDE_USER_PWFILE
in the configuration file config.h, then chooses
'/~' to be the special string and the server consults the
system password file and changes the root data directory to
"/home/john/public_html" (assuming "/home/john"
is "john's" home directory) and simultaneously deletes the
"/~john". Thus, the URL becomes
"http://hostname/foo.html" with root directory
"/home/john/public_html" so the file accessed is
"/home/john/public_html/foo.html". Both the string
"/~" and the subdirectory "public_html" are
configurable by changing values in config.h. They are called #define TILDE_USER_STRING
and #define PUB_HTML
respectively.
Thus, to avoid the problematic character '~' a maintainer
might set #define TILDE_USER_STRING
to "/people/" and might set #define PUB_HTML
to "wwwstuff". Then the URL
"http://hostname/people/john/foo.html" would result in the
equivalent of a URL request for "/foo.html" with a data root
of "/home/john/wwwstuff". Note that #define TILDE_USER_STRING
must be everything before the user name at the beginning of the URL.
Thus it needs to be "/people/" and not
"/people".
As a security measure the maintainer can set a variable #define LEAST_UID
(with default value 100) in config.h and any attempt to use
"/~user/" will fail if the user id of "user" is
less than this value.
A second method of establishing an alternate data hierarchy does not use
the password file but a table supplied by the maintainer. This method is
enabled by defining the #define TILDE_TABLE
variable in config.h.
This should be the complete system pathname of a file containing names
and their corresponding data hierarchy directories.
For example, if config.h contains the
line:
#define TILDE_TABLE /usr/local/etc/wn.dir.table
and the file "wn.dir.table" contains lines like:
john:/home/john/public_html
bob:/home/bob/public_html
then the URL "http://hostname/~bob/foo.html" will be
translated to a request for "/foo.html" with the data root
directory set to "/home/bob/public_html". The file
consulted should have lines consisting of a name followed by a
':' followed by the full system path of the desired root
data directory. Of course, the name need not be the name of a user. One
difference with this method is that the #define PUB_HTML
value from config.h is not
used and if you want it to be part of the path it should be in the path
part of each entry in your table.
This method of changing hierarchies uses the #define TILDE_USER_STRING
in precisely the same way that the password file method does. In other
words, if #define TILDE_USER_STRING
is defined to be "/people/" instead of '/~'
then "http://hostname/people/john/foo.html" will be
translated to a request for "/foo.html" with root data
directory "/home/john/public_html".
More precisely when the #define TILDE_USER_STRING
is at the start of the URI it is deleted and everything after it up to
the next '/' is taken to be the name to be looked up in the
table or password file. This name is also discarded and the remainder of
the URI is taken to be the path of the desired document relative to the
new data hierarchy root.
When you use the table lookup method to retarget data root directories of
user hierarchies, you can specify a directory that is not even on the
local server host. To do this, specify a lookup table entry consisting
of a name, a double colon (rather than a single colon), and the URL to
the user's data root directory. For example, if user "jim"
has a data root that is accessed as "~jim" on
"otherhost", you can specify the lookup table entry like
this:
jim::http://otherhost/~jim
Then when a client sends a request like
"http://hostname/people/jim/path/file.html" to your server,
the server will return a redirect to the client for
"http://otherhost/~jim/path/file.html".
The ability to specify non-local user hierarchies is useful when you run
a primary web server (e.g. "www.your.site.edu") and want all
your users to be able to advertise home page URLs that begin with
"http://www.your.site.edu/" whether or not their accounts
are actually on that host.