File: access.html

package info (click to toggle)
wn 2.0.5-3
links: PTS
area: main
in suites: slink
size: 2,208 kB
ctags: 1,499
sloc: ansic: 14,439; sh: 2,430; perl: 1,360; makefile: 291
file content (702 lines) | stat: -rw-r--r-- 27,867 bytes
<!doctype html public "-//W3C//DTD HTML 3.2 Final//EN">
<html>
  <head>
    <title>Limiting Access to Your WN Hierarchy</title>

    <link rev="made" href="mailto:john@math.nwu.edu">

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
    <meta http-equiv="last-modified" content="Fri, 09 Oct 1998 18:18:09 GMT">
    <meta http-equiv="keywords" content="WN access, wnauth, wn_mkpasswd">
  </head>

  <body bgcolor="#FFFFFF">
    <p>
      <a href="http://hopf.math.nwu.edu/"><img
        src="images/powered.jpg"
        border="0"
        width="190"
        height="41"
        align="right"
        alt="WN home page"
      ></a>
    </p>

    <strong>Version 2.0.3</strong>

    <br>

    <!-- pnuts --> <a href="range.html">[Previous]</a> <a href="tilde.html">[Next]</a> <a href="manual.html">[Up]</a> <a href="manual.html">[Top]</a> <a href="dosearch.html">[Search]</a> <a href="docindex.html">[Index]</a>

    <br clear="right">

    <hr size="4">
    <!-- #start -->

    <h2 align="center">Limiting Access to Your <em>WN</em> Hierarchy</h2>
    <hr size="4">

    <p>
      There are two ways to limit access to your hierarchy.  You can restrict
      access by hostname or IP address and you can restrict access to users
      whose name and password are in a file on your server
      (authentication). You can, of course, do both.  To restrict access to an
      entire hierarchy you must restrict access to each of its subdirectories.
    </p>

    <blockquote>
      <em>Warning:</em> If access to a directory is restricted by either of the
      ways described here the restrictions affect only that one directory and
      not its subdirectories.
    </blockquote>


    <h3>10.1 <a name="ip">Access Control Files: Limiting Access by Hostname or
    IP Address</a></h3>

    <p>
      If you have opted to limit access to your server in this way you do so by
      setting the value of the <code><a
      href="appendixB.html#ddir.accessfile">Accessfile=</a></code> in the <a
      href="index_desc.html#index"><code>index</code></a> file for a directory.
      In the <a href="appendixB.html#ddir">directory directive</a> part of an
      <a href="index_desc.html#index"><code>index</code></a> file, a line like:
    </p>

    <blockquote>
      <code>
        <a href="appendixB.html#ddir.accessfile">Accessfile=</a>~/dir/.access
      </code>
    </blockquote>

    <p>
      specifies that the the access control file
      <code>wnroot/dir/.access</code> contains restrictions on what sites are
      allowed to access this directory.  The <code><a
      href="appendixB.html#ddir.accessfile">Accessfile=</a></code> directive
      takes the value of a path to a file in different forms.  If the path
      begins with a '<code>/</code>' or with '<code>~/</code>' then it is
      relative to the <em>WN</em> hierarchy root, and otherwise it is relative
      to the directory containing the <a
      href="index_desc.html#index"><code>index</code></a> file in which the
      directive occurs.  In particular the access file must be located within
      your <em>WN</em> hierarchy.
    </p>

    <blockquote>
      <em>Warning:</em> If the <code><a
      href="appendixB.html#ddir.attributes.serveall">Attributes=serveall</a></code>
      directive is used in a directory with restricted access be sure the
      access file is not serveable.  You can do this by giving it a name
      starting with '<code>.</code>' or ending with '<code>~</code>', or
      better, put it in a directory from which nothing is served.
    </blockquote>

    <p>
      Also note that limiting access to this directory does not limit access to
      subdirectories.  The <code><a
      href="appendixB.html#ddir.accessfile">Accessfile=</a></code> line must
      occur in the <a href="index_desc.html#index"><code>index</code></a> file
      of each directory you want restricted.  Of course, they can all refer to
      the same file.  To use the same file for several directories be sure to
      use the "<code><a
      href="appendixB.html#ddir.accessfile">Accessfile=</a>~/dir/.access</code>"
      form of the directive so the line can be the same for every <a
      href="index_desc.html#index"><code>index</code></a> file.
    </p>

    <p>
      This will limit access to the server to those clients with an IP address
      or subnet address listed (and not excluded) in the file
      <code>.access</code> listed in the <code><a
      href="appendixB.html#ddir.accessfile">Accessfile=</a></code> directive.
    </p>

    <p>
      If a recursive <a href="search.html#title">title search</a> or <a
      href="search.html#keyword">keyword search</a> is requested and some
      directories have restricted access only those directories which have the
      same access file as the directory where the search started will be
      searched.  In fact the path must be the same in the <code><a
      href="appendixB.html#ddir.accessfile">Accessfile=</a></code> directive
      for both directories (and must necessarily be of the form "<code><a
      href="appendixB.html#ddir.accessfile">Accessfile=</a>~/dir/.access</code>"
      or "<code><a
      href="appendixB.html#ddir.accessfile">Accessfile=</a>/dir/.access</code>"
      rather than "<code><a
      href="appendixB.html#ddir.accessfile">Accessfile=</a>.access</code>").
    </p>

    <p>
      There are three possible formats for lines in the access file.  First you
      may list the domain names of the machines using wild cards provided the
      machines all have proper <code>PTR</code> <a
      href="http://www.dns.net/dnsrd/rr.html">DNS resource record</a>.  For
      example the line:
    </p>

    <blockquote>
      <code>
        dogbert.widget.com
      </code>
    </blockquote>

    <p>
      allows access to one host. To allow access to all machines in the
      <code>widget.com</code> domain, use the line:
    </p>

    <blockquote>
      <code>
        *.widget.com
      </code>
    </blockquote>

    <p>
      Note that this will not allow access to a machine called
      <code>widget.com</code> if it exists.  One would need to add in the line
      <code>widget.com</code> to allow it access.
    </p>

    <p>
      You can also allow access by IP address and, in general, this is somewhat
      more secure than using the hostnames.  There are two line formats for IP
      addresses.  The first is to explicitly list an IP address like
      <code>129.111.222.123</code> or a subnet address like
      <code>129.111.222.</code> or <code>129.111.</code>.  In case a subnet
      address is listed it must end with a period like:
    </p>

    <blockquote>
      <code>
        129.111.222.
      </code>
    </blockquote>

    <p>
      or
    </p>

    <blockquote>
      <code>
        132.123.
      </code>
    </blockquote>

    <p>
      but complete IP addresses like <code>129.111.222.123</code> should not
      end with a period.  If a subnet address is listed any client with an IP
      address beginning with that subnet address will be allowed access.
    </p>

    <p>
      The second format for IP address restriction uses a net address, net mask
      pair with the two parts separated by a '<code>/</code>'.  For example:
    </p>

    <blockquote>
      <code>
        129.111.222.0/255.255.255.0
      </code>
    </blockquote>

    <p>
      The presence of the '<code>/</code>' indicates to the server that this
      format is being used.  The part before the '<code>/</code>' is the "net
      address" and the part after is the "net mask".  The server will then take
      the IP address of the remote client, do a logical "and" of each of its
      four parts with the corresponding four parts of the net mask
      (<code>255.255.255.0</code> in this example) and check that the four
      results agree with the four parts of the net address
      (<code>129.111.222.0</code>).  So the access file line above will match
      (and allow access to) precisely those machines with IP address of the
      form <code>129.111.222.x</code> because the '<code>x</code>" part is
      "anded" with <code>0</code> and hence becomes <code>0</code>, while the
      first three parts are "anded" with <code>255</code> and hence unchanged,
      so they must equal <code>129</code>, <code>111</code>, and
      <code>222</code> respectively.
    </p>

    <p>
      Note that if you have <a
      href="configmacros.html#NO_DNS_HOSTNAMES"><code>#define&nbsp;NO_DNS_HOSTNAMES</code></a>
      in the <a href="configmacros.html"><code>config.h</code></a> file you
      must use one of the IP address formats above and not the format using a
      domain name.  This is because <a
      href="configmacros.html#NO_DNS_HOSTNAMES"><code>#define&nbsp;NO_DNS_HOSTNAMES</code></a>
      causes <em>WN</em> never to convert IP addresses to hostnames.
    </p>

    <p>
      You can also exclude IP addresses or domain names by prefixing them with
      an '<code>!</code>', so if the access file contained only the lines:
    </p>

    <blockquote>
      <code>
        !speedy.acns.nwu.edu
        <br>
        *
      </code>
    </blockquote>

    <p>
      Access would be permitted to every machine <em>except</em> speedy (the
      <code>*</code> matches, and allows access to, anything).  Likewise:
    </p>

    <blockquote>
      <code>
        !129.111.
        <br>
        !129.222.0.0/255.255.0.0
        <br>
        *
      </code>
    </blockquote>

    <p>
      would allow access to everyone except those on subnet
      <code>129.111</code> or on subnet <code>129.222</code>.  In general
      prefixing a line (in any of the three formats) with '<code>!</code>'
      causes immediate denial of access to any matching host.  The first
      matching line (with or without leading '<code>!</code>') for a host is
      the one which takes effect.  Once a match is found access will be granted
      (or denied if a '<code>!</code>' is present) and no subsequent lines in
      the access file will be considered.
    </p>

    <p>
      A line in an access file cannot exceed 255 characters in length and every
      line must end with a newline (some editors don't guarantee this and the
      last line of a file may not have a newline).  A blank line at the end is
      fine.  If these conditions are not met an error of type "<code>Access
      file line overflow</code>" will be generated.
    </p>



    <h4>10.1.1 <a name="ip.privilege">Privileged Sites</a></h4>

    <p>
      You may also designate "privileged sites" in your access files.  If you
      list a site in an access file with a '<code>+</code>' prefix like:
    </p>

    <blockquote>
      <code>
        +hopf.math.nwu.edu
        <br>
        +123.123.123.1
        <br>
        +111.111.111.0/255.255.255.0
      </code>
    </blockquote>

    <p>
      then requests from that site will be exempt from any password
      requirements (as described below).  In other words, no username/password
      pair will be required for requests from these sites, even if they are
      required from other sites.
    </p>

    <p>
      Obviously the '<code>+</code>' and '<code>!</code>' prefixes for access
      file lines are mutually exclusive.
    </p>



    <h4>10.1.2 <a name="ip.access_error">Customized Error Messages</a></h4>

    <p>
      It is possible to specify a URL referring to a customized document
      intended as an error message when access is denied.  The easiest way to
      do this is to place the line:
    </p>

    <blockquote>
      <code>
        Access-denied-URL=http://host/dir/foo.html
      </code>
    </blockquote>

    <p>
      or the line:
    </p>


    <blockquote>
      <code>
        Access-denied-URL=/dir/foo.html
      </code>
    </blockquote>

    <p>
      at the beginning of the access file.  When this is done and a request is
      denied because of failure to meet the restrictions in that access file,
      the browser will be redirected to the URL
      "<code>http://host/dir/foo.html</code>" or "<code>/dir/foo.html</code>".
      <code><a
      href="appendixB.html#ddir.access-denied-url">Access-denied-URL=</a></code>
      is also a legal <a href="appendixB.html#ddir">directory directive</a>
      which may be placed in an <a
      href="index_desc.html#index"><code>index</code></a> file.
    </p>


    <h3>10.2 <a name="authenticate">Limiting Access by Password
    Authentication</a></h3>

    <p>
      You can also maintain a password file (or files) on your system and
      restrict access to those users who can supply a valid user name and
      password.  This is the so-called "Basic" authentication described in the
      <a href="http://www.w3c.org/Protocols/">HTTP/1.1</a> protocol.
    </p>

    <blockquote>
      <em>Warning:</em> I would strongly advise against using basic
      authentication described here to protect sensitive information on a
      server which runs on system on which untrusted users have accounts.
    </blockquote>

    <p>
      Notice that if none of the options <a
      href="appendixA1.html#t_opt"><code>-t</code></a>, <a
      href="appendixA1.html#T_opt"><code>-T</code></a> and <a
      href="appendixA1.html#u_opt"><code>-u</code></a> are used then a user
      with his own home page can make a symbolic link to any file readable by
      the server and that document will be served.  This is true even if the
      linked to document is in a password protected directory with limited
      access or is outside the server data hierarchy.
    </p>

    <p>
      The use of basic authentication with <em>WN</em> involves two additional
      programs which can be found in the <code>/bin</code> directory of the
      distribution.  The first of these is <code>wn_mkpasswd</code> which is a
      <a href="http://www.perl.org/">perl</a> utility for creating and altering
      password files. It should be run the first time with the command:
    </p>

    <blockquote>
      <code>
        wn_mkpasswd -n filename
      </code>
    </blockquote>

    <p>
      This prompts you for a username and password and then creates a password
      file called "<code>filename</code>" with that entry.  On subsequent uses
      the <code>-n</code> argument should be omitted so that entries will be
      added to the existing file instead of starting a new one (the
      <code>-n</code> is for "new").  If a subsequent entry is made with the
      same user name the entry for that user will be replaced.  If the
      "<code>filename</code>" argument is omitted then the default name of
      <code>wnpasswd</code> is used.  There is another optional argument which
      may be used with this program.  The command:
    </p>

    <blockquote>
      <code>
        wn_mkpasswd -D filename
      </code>
    </blockquote>

    <p>
      causes a UNIX <code>NDBM</code> database to be created or used instead of
      a simple flat file.  This is may be useful if you have a very large
      number of password entries.  Depending on your system, the database may
      reside in the two files <code>filename.dir</code> and
      <code>filename.pag</code>, or in a single file <code>filename.db</code>.
      The <code>-n</code> option has no effect when combined with the
      <code>-D</code> option.  To create a new database you must remove or
      rename the <code>.pag</code> and <code>.dir</code> or <code>.db</code>
      files.  To remove a single entry from a password file use the command
      "<code>wn_mkpasswd -d filename</code>" or "<code>wn_mkpasswd -D
      filename</code>" for an <code>NDBM</code> database.
    </p>

    <blockquote>
      <em>Note:</em> To enable the <code>NDBM</code> features of
      <code>wnauth</code> you will have to uncomment the lines in
      <code>wnauth/Makefile</code> starting with <code>#DBMFLAG</code> and
      <code>#DBMLIB</code> and recompile the <code>wnauth</code> program by
      running the UNIX <a
      href="http://linux-howto.com/man/man1/make.1.html"><code>make(1)</code></a>
      utility in the <code>/wnauth</code> directory.
    </blockquote>

    <p>
      Once you have created your password file and made sure that it is
      readable by the user id under which the server will run, you are ready to
      set up the <em>WN</em> authentication module, called <a
      href="module.html#authorization"><code>wnauth</code></a>.  This is done
      on a per directory basis by three entries in directory record of the <a
      href="index_desc.html#index"><code>index</code></a> file.  Entries like:
    </p>

    <blockquote>
      <code>
        <a
        href="appendixB.html#ddir.authorization-realm">Authorization-realm=</a>myrealm@host.domain
        <br>
        <a
        href="appendixB.html#ddir.authorization-module">Authorization-module=</a>~/cgi-bin/wnauth&nbsp;"~/dir/wnpasswd"
        <br>
        <a
        href="appendixB.html#ddir.authorization-type">Authorization-type=</a>basic
      </code>
    </blockquote>

    <p>
      in the directory record specify that the authentication module <a
      href="module.html#authorization"><code>wnauth</code></a> is being used to
      check user's passwords and that it should consult the password file
      "<code>wnpasswd</code>" in <code>wnroot/dir/</code>.  If instead of the
      password file "<code>wnpasswd</code>" you are using a <code>NDBM</code>
      database "<code>wnpasswd.dir</code>" and "<code>wnpasswd.pag</code>"
      created with "<code>wn_mkpasswd -D</code>" as described above (or created
      some other way), then you should use the line:
    </p>

    <blockquote>
      <code>
        <a
        href="appendixB.html#ddir.authorization-module">Authorization-module=</a>~/cgi-bin/wnauth&nbsp;-D&nbsp;"~/dir/wnpasswd"
      </code>
    </blockquote>

    <p>
      The password file can also be specified with the <code>-P</code> option
      as in:
    </p>

    <blockquote>
      <code>
        <a
        href="appendixB.html#ddir.authorization-module">Authorization-module=</a>~/cgi-bin/wnauth&nbsp;-P&nbsp;wnpasswd
      </code>
    </blockquote>

    <p>
      The name of the password file can be given in three different formats:
      beginning with a '<code>/</code> meaning it is relative to the system
      root, beginning with '<code>~/</code>' indicating it is relative to the
      <em>WN</em> hierarchy root, or something else indicating it is relative
      to the directory containing this <a
      href="index_desc.html#index"><code>index</code></a> file.  If you use the
      '<code>~/...</code>' form it is a good idea to put the file name in
      double quotes as shown above to prevent the shell from trying to
      interpret the '<code>~</code>'.
    </p>

    <blockquote>
      <em>Warning:</em> If the <code><a
      href="appendixB.html#ddir.attributes.serveall">Attributes=serveall</a></code>
      directory directive is used in a directory with access restricted by
      password, be sure the password file is not serveable.  You can do this by
      giving it a name starting with '<code>.</code>' or ending with
      '<code>~</code>', or better, put it in a directory from which nothing is
      served.
    </blockquote>

    <p>
      Note that if you designate a <a href="#ip.privilege">privileged site</a>
      in your access control file then any users from that site will not be
      requested to supply a user name and password.
    </p>

    <p>
      For security reasons when you use <a
      href="module.html#authorization"><code>wnauth</code></a> or any <a
      href="appendixB.html#ddir.authorization-module"><code>Authorization-Module=</code></a>
      <em>you are required to use either the <a
      href="appendixA1.html#t_opt"><code>-t</code></a> or <a
      href="appendixA1.html#T_opt"><code>-T</code></a> option or the <a
      href="appendixA1.html#a_opt"><code>-a</code></a> or <a
      href="appendixA1.html#A_opt"><code>-A</code></a> option</em> when the
      server is run and to have the <code>index.cache</code> file in the
      protected directory owned by the trusted user or group. This is to guard
      against counterfeit authentication modules. Note that the four command
      line arguments <a href="appendixA1.html#a_opt"><code>-a</code></a>, <a
      href="appendixA1.html#A_opt"><code>-A</code></a>, <a
      href="appendixA1.html#t_opt"><code>-t</code></a> and <a
      href="appendixA1.html#T_opt"><code>-T</code></a> all take a numeric
      argument.  Thus the command should be
      "<code>./wnsd&nbsp;-t&nbsp;203</code>" and <em>not</em>
      "<code>./wnsd&nbsp;-t&nbsp;joe</code>" if user <code>joe</code> has user
      id <code>203</code>.
    </p>

    <p>
      The <code><a
      href="appendixB.html#ddir.authorization-realm">Authorization-Realm=</a></code>
      line is to notify the client that for any document on this server with
      the same realm as this one, the same username/password combination will
      be valid, so the client need not ask the user for a username and
      password, but can reuse the one supplied for the first document with this
      realm.  For security reasons it is a good idea to put your host and
      domain name in the realm.  This may at least discourage attempts at other
      sites to forge your realm in order to collect user passwords.  Your users
      should also be warned never to enter their password if the realm
      displayed when they are prompted for a password contains a different
      hostname than the one in the URL they are trying to access.
    </p>

    <p>
      If you use different realms on the same server you should be aware that
      popular browsers are somewhat cavalier in their treatment of realms.  In
      particular once a username/password pair has been accepted a browser
      might well continue to use it on the same site without checking the realm
      until authentication fails.  This practice of trying to guess the
      username/password is more efficient if the guess is correct and most of
      the time it is.
    </p>

    <p>
      Also note that <em>password protecting a directory does not protect its
      subdirectories</em>.  The three "<code>Authorization</code>" lines must
      occur in the <a href="index_desc.html#index"><code>index</code></a> file
      of each directory you want to protect.  Of course, these lines can all be
      identical for different directories if you use the:
    </p>

    <blockquote>
      <code>
        <a
        href="appendixB.html#ddir.authorization-module">Authorization-module=</a>~/cgi-bin/wnauth&nbsp;~/dir/wnpasswd
      </code>
    </blockquote>

    <p>
      form to specify locations relative to your <em>WN</em> root.
    </p>

    <p>
      There is also support for a "<code>group</code>" file with
      authentication.  This feature is invoked by using the <code>-g</code> and
      <code>-G</code> options with the <a
      href="module.html#authorization"><code>wnauth</code></a> authentication
      module. The line:
    </p>

    <blockquote>
      <code>
        <a
        href="appendixB.html#ddir.authorization-module">Authorization-module=</a>wnauth&nbsp;-g&nbsp;grpname&nbsp;-G&nbsp;foo&nbsp;-P&nbsp;wnpasswd
      </code>
    </blockquote>

    <p>
      means to use the group name "<code>grpname</code>" and the group file
      "<code>foo</code>".  The group file is a file in the format of a UNIX <a
      href="http://linux-howto.com/man/man5/group.5.html"><code>group(5)</code></a>
      configuration file.  That is, it has lines of the form:
    </p>

    <blockquote>
      <code>
        grpname:*:99:user1,user3,user5
      </code>
    </blockquote>

    <p>
      where the fields are separated by colons, the first field is a group
      name, and the fourth field is a comma separated list of user names.  <a
      href="module.html#authorization"><code>wnauth</code></a> will ignore the
      second and third fields.  If the line above is in the file
      <code>foo</code> and <a
      href="module.html#authorization"><code>wnauth</code></a> is invoked as
      above then a user will be granted access provided the supplied password
      matches that in the <code>wnpasswd</code> file and the user's username is
      in the list after the second '<code>:</code>' in the line starting with
      the group name.  Thus, in this example users <code>user1</code>,
      <code>user3</code>, and <code>user5</code> will be given access if they
      provide valid passwords and other users will not.
    </p>

    <p>
      The format of a group file used by <a
      href="http://www.apache.org">Apache</a> is also supported.  This format
      has lines of the form:
    </p>

    <blockquote>
      <code>
        grpname:&nbsp;user1&nbsp;user3&nbsp;user5
      </code>
    </blockquote>

    <p>
      which is the group name, a single colon and a space separated list of
      user names.
    </p>

    <p>
      It is possible to specify a custom error message to be sent when password
      authentication fails because of an incorrect password or username as in:
    </p>

    <blockquote>
      <code>
        <a
        href="appendixB.html#ddir.auth-denied-file">Auth-denied-file=</a>~/dir/foo.html
      </code>
    </blockquote>

    <p>
      This specifies that any request for a document in this directory which is
      denied because of an authorization module restriction results in the file
      <code>~/dir/foo.html</code> being sent instead.  A default value for all
      directories can be set by uncommenting the <a
      href="configmacros.html#AUTH_DENIED_FILE"><code>#define&nbsp;AUTH_DENIED_FILE</code></a>"
      line in <a href="configmacros.html"><code>config.h</code></a> and
      recompiling.  Note that this is not a URL but the name of a file whose
      content is to be sent as error text when authentication is denied.  If
      the file name starts with '<code>~/</code>' as above it is assumed to be
      relative to the <em>WN</em> root directory.  Otherwise it is assumed to
      be a path relative to the directory containing the <a
      href="index_desc.html#index"><code>index</code></a> file.
    </p>

    <p>
      The "Basic" authentication scheme is flawed in that it involves the
      transmission of essentially unencoded passwords over the network.  It is
      relatively easy for unscrupulous people to obtain "sniffer" software
      which allows eavesdropping on all local network traffic.  This means, in
      particular, that it is possible to intercept passwords.
    </p>

    <p>
      This particular problem is remedied by the <a
      href="http://www.w3c.org/Protocols/">HTTP/1.1</a> Digest Authentication
      scheme.  <a href="http://hopf.math.nwu.edu/digestauth/draft.rfc">Digest
      authentication</a> is <a
      href="http://hopf.math.nwu.edu/digestauth/index.html">supported
      experimentally</a> by <em>WN,</em> but has the rather severe drawback
      that no publicly available clients currently support it.  It is
      experimental, because I have no client to test it and hence it has barely
      been tested.
    </p>


    <!-- #end -->
    <hr size="4">

    <address>
      <em>WN</em> version 2.0.3
      <br>
      Copyright &copy; 1998 <a href="mailto:john@math.nwu.edu">John Franks
      &lt;john@math.nwu.edu&gt;</a>
      <br>
      licensed under the <a href="http://www.opencontent.org/opl.html">
      OpenContent Public License</a>
      <br>
      last-modified: Fri, 09 Oct 1998 18:18:09 GMT
    </address>

    <!-- pnuts --> <a href="range.html">[Previous]</a> <a href="tilde.html">[Next]</a> <a href="manual.html">[Up]</a> <a href="manual.html">[Top]</a> <a href="dosearch.html">[Search]</a> <a href="docindex.html">[Index]</a>
  </body>
</html>