--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<modulesynopsis>
+
+<name>mod_access</name>
+
+<description>Provides access control based on client hostname, IP
+address, or other characteristics of the client request.</description>
+
+<status>Obsolete</status>
+<hint>replaced by <module>mod_authz_host</module> since 2.0.44</hint>
+<sourcefile>mod_access.c</sourcefile>
+<identifier>access_module</identifier>
+<compatibility>Available only in versions up to 2.0.43</compatibility>
+
+<summary>
+ <note type="warning"><title>This module is obsolete!</title>
+ <p>Note, that this module has been marked as obsolete. A bunch
+ of modules was introduced in Apache version 2.0.44 that
+ support the new Authentication/Authorization provider mechnism.</p>
+
+ <p>If you want to use host based access control, you have to invoke the
+ <module>mod_authz_host</module> module now.</p>
+
+ <p>This document is kept only for historical reasons and no
+ longer maintained.</p>
+ </note>
+
+ <p>The directives provided by mod_access are used in <directive
+ module="core" type="section">Directory</directive>, <directive
+ module="core" type="section">Files</directive>, and <directive
+ module="core" type="section">Location</directive> sections as well as
+ <code><a href="core.html#accessfilename">.htaccess</a></code>
+ files to control access to particular parts of the server. Access
+ can be controlled based on the client hostname, IP address, or
+ other characteristics of the client request, as captured in <a
+ href="../env.html">environment variables</a>. The <directive
+ module="mod_access" status="obsolete">Allow</directive> and <directive
+ module="mod_access" status="obsolete">Deny</directive> directives are used to
+ specify which clients are or are not allowed access to the server,
+ while the <directive module="mod_access" status="obsolete">Order</directive>
+ directive sets the default access state, and configures how the
+ <directive module="mod_access" status="obsolete">Allow</directive> and <directive
+ module="mod_access" status="obsolete">Deny</directive> directives interact with each
+ other.</p>
+
+ <p>Both host-based access restrictions and password-based
+ authentication may be implemented simultaneously. In that case,
+ the <directive module="core">Satisfy</directive> directive is used
+ to determine how the two sets of restrictions interact.</p>
+
+ <p>In general, access restriction directives apply to all
+ access methods (<code>GET</code>, <code>PUT</code>,
+ <code>POST</code>, etc). This is the desired behavior in most
+ cases. However, it is possible to restrict some methods, while
+ leaving other methods unrestricted, by enclosing the directives
+ in a <directive module="core" type="section">Limit</directive> section.</p>
+</summary>
+
+<seealso><directive module="core">Satisfy</directive></seealso>
+<seealso><directive module="core">Require</directive></seealso>
+
+<directivesynopsis>
+<name>Allow</name>
+
+<description>Controls which hosts can access an area of the
+server</description>
+<syntax> Allow from
+ all|<var>host</var>|env=<var>env-variable</var>
+ [<var>host</var>|env=<var>env-variable</var>] ...</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>Limit</override>
+
+<usage>
+
+ <p>The <directive>Allow</directive> directive affects which hosts can
+ access an area of the server. Access can be controlled by
+ hostname, IP Address, IP Address range, or by other
+ characteristics of the client request captured in environment
+ variables.</p>
+
+ <p>The first argument to this directive is always
+ <code>from</code>. The subsequent arguments can take three
+ different forms. If <code>Allow from all</code> is specified, then
+ all hosts are allowed access, subject to the configuration of the
+ <directive module="mod_access" status="obsolete">Deny</directive> and <directive
+ module="mod_access" status="obsolete">Order</directive> directives as discussed
+ below. To allow only particular hosts or groups of hosts to access
+ the server, the <var>host</var> can be specified in any of the
+ following formats:</p>
+
+ <dl>
+ <dt>A (partial) domain-name</dt>
+
+ <dd>Example: <code>Allow from apache.org</code><br />
+ Hosts whose names match, or end in, this string are allowed
+ access. Only complete components are matched, so the above
+ example will match <code>foo.apache.org</code> but it will
+ not match <code>fooapache.org</code>. This configuration will
+ cause the server to perform a reverse DNS lookup on the
+ client IP address, regardless of the setting of the <directive
+ module="core">HostnameLookups</directive>
+ directive.</dd>
+
+ <dt>A full IP address</dt>
+
+ <dd>Example: <code>Allow from 10.1.2.3</code><br />
+ An IP address of a host allowed access</dd>
+
+ <dt>A partial IP address</dt>
+
+ <dd>Example: <code>Allow from 10.1</code><br />
+ The first 1 to 3 bytes of an IP address, for subnet
+ restriction.</dd>
+
+ <dt>A network/netmask pair</dt>
+
+ <dd>Example: <code>Allow from
+ 10.1.0.0/255.255.0.0</code><br />
+ A network a.b.c.d, and a netmask w.x.y.z. For more
+ fine-grained subnet restriction.</dd>
+
+ <dt>A network/nnn CIDR specification</dt>
+
+ <dd>Example: <code>Allow from 10.1.0.0/16</code><br />
+ Similar to the previous case, except the netmask consists of
+ nnn high-order 1 bits.</dd>
+ </dl>
+
+ <p>Note that the last three examples above match exactly the
+ same set of hosts.</p>
+
+ <p>IPv6 addresses and IPv6 subnets can be specified as shown
+ below:</p>
+
+ <example>
+ Allow from fe80::a00:20ff:fea7:ccea<br />
+ Allow from fe80::a00:20ff:fea7:ccea/10
+ </example>
+
+ <p>The third format of the arguments to the
+ <directive>Allow</directive> directive allows access to the server
+ to be controlled based on the existence of an <a
+ href="../env.html">environment variable</a>. When <code>Allow from
+ env=<var>env-variable</var></code> is specified, then the request is
+ allowed access if the environment variable <var>env-variable</var>
+ exists. The server provides the ability to set environment
+ variables in a flexible way based on characteristics of the client
+ request using the directives provided by
+ <module>mod_setenvif</module>. Therefore, this directive can be
+ used to allow access based on such factors as the clients
+ <code>User-Agent</code> (browser type), <code>Referer</code>, or
+ other HTTP request header fields.</p>
+
+ <example><title>Example:</title>
+ SetEnvIf User-Agent ^KnockKnock/2.0 let_me_in<br />
+ <Directory /docroot><br />
+ <indent>
+ Order Deny,Allow<br />
+ Deny from all<br />
+ Allow from env=let_me_in<br />
+ </indent>
+ </Directory>
+ </example>
+
+ <p>In this case, browsers with a user-agent string beginning
+ with <code>KnockKnock/2.0</code> will be allowed access, and all
+ others will be denied.</p>
+</usage>
+
+</directivesynopsis>
+
+<directivesynopsis>
+
+<name>Deny</name>
+
+<description>Controls which hosts are denied access to the
+server</description>
+
+<syntax> Deny from
+ all|<var>host</var>|env=<var>env-variable</var>
+ [<var>host</var>|env=<var>env-variable</var>] ...</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>Limit</override>
+
+<usage>
+ <p>This directive allows access to the server to be restricted
+ based on hostname, IP address, or environment variables. The
+ arguments for the <directive>Deny</directive> directive are
+ identical to the arguments for the <directive
+ module="mod_access" status="obsolete">Allow</directive> directive.</p>
+</usage>
+
+</directivesynopsis>
+
+<directivesynopsis>
+
+<name>Order</name>
+
+<description>Controls the default access state and the order in which
+<directive>Allow</directive> and <directive>Deny</directive> are
+evaluated.</description>
+
+<syntax> Order <var>ordering</var></syntax>
+<default>Order Deny,Allow</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>Limit</override>
+
+<usage>
+
+ <p>The <directive>Order</directive> directive controls the default
+ access state and the order in which <directive
+ module="mod_access" status="obsolete">Allow</directive> and <directive
+ module="mod_access" status="obsolete">Deny</directive> directives are evaluated.
+ <var>Ordering</var> is one of</p>
+
+ <dl>
+ <dt>Deny,Allow</dt>
+
+ <dd>The <directive module="mod_access" status="obsolete">Deny</directive> directives
+ are evaluated before the <directive
+ module="mod_access" status="obsolete">Allow</directive> directives. Access is
+ allowed by default. Any client which does not match a
+ <directive module="mod_access" status="obsolete">Deny</directive> directive or does
+ match an <directive module="mod_access" status="obsolete">Allow</directive>
+ directive will be allowed access to the server.</dd>
+
+ <dt>Allow,Deny</dt>
+
+ <dd>The <directive module="mod_access" status="obsolete">Allow</directive>
+ directives are evaluated before the <directive
+ module="mod_access" status="obsolete">Deny</directive> directives. Access is denied
+ by default. Any client which does not match an <directive
+ module="mod_access" status="obsolete">Allow</directive> directive or does match a
+ <directive module="mod_access" status="obsolete">Deny</directive> directive will be
+ denied access to the server.</dd>
+
+ <dt>Mutual-failure</dt>
+
+ <dd>Only those hosts which appear on the <directive
+ module="mod_access" status="obsolete">Allow</directive> list and do not appear on
+ the <directive module="mod_access" status="obsolete">Deny</directive> list are
+ granted access. This ordering has the same effect as <code>Order
+ Allow,Deny</code> and is deprecated in favor of that
+ configuration.</dd>
+ </dl>
+
+ <p>Keywords may only be separated by a comma; no whitespace is
+ allowed between them. Note that in all cases every <directive
+ module="mod_access" status="obsolete">Allow</directive> and <directive
+ module="mod_access" status="obsolete">Deny</directive> statement is evaluated.</p>
+
+ <p>In the following example, all hosts in the apache.org domain
+ are allowed access; all other hosts are denied access.</p>
+
+ <example>
+ Order Deny,Allow<br />
+ Deny from all<br />
+ Allow from apache.org
+ </example>
+
+ <p>In the next example, all hosts in the apache.org domain are
+ allowed access, except for the hosts which are in the
+ foo.apache.org subdomain, who are denied access. All hosts not
+ in the apache.org domain are denied access because the default
+ state is to deny access to the server.</p>
+
+ <example>
+ Order Allow,Deny<br />
+ Allow from apache.org<br />
+ Deny from foo.apache.org
+ </example>
+
+ <p>On the other hand, if the <directive>Order</directive> in the last
+ example is changed to <code>Deny,Allow</code>, all hosts will
+ be allowed access. This happens because, regardless of the
+ actual ordering of the directives in the configuration file,
+ the <code>Allow from apache.org</code> will be evaluated last
+ and will override the <code>Deny from foo.apache.org</code>.
+ All hosts not in the <code>apache.org</code> domain will also
+ be allowed access because the default state will change to
+ <var>allow</var>.</p>
+
+ <p>The presence of an <directive>Order</directive> directive can affect
+ access to a part of the server even in the absence of accompanying
+ <directive module="mod_access" status="obsolete">Allow</directive> and <directive
+ module="mod_access" status="obsolete">Deny</directive> directives because of its effect
+ on the default access state. For example,</p>
+
+ <example>
+ <Directory /www><br />
+ <indent>
+ Order Allow,Deny<br />
+ </indent>
+ </Directory>
+ </example>
+
+ <p>will deny all access to the <code>/www</code> directory
+ because the default access state will be set to
+ <var>deny</var>.</p>
+
+ <p>The <directive>Order</directive> directive controls the order of access
+ directive processing only within each phase of the server's
+ configuration processing. This implies, for example, that an
+ <directive module="mod_access" status="obsolete">Allow</directive> or <directive
+ module="mod_access" status="obsolete">Deny</directive> directive occurring in a
+ <directive module="core" type="section">Location</directive> section will
+ always be evaluated after an <directive
+ module="mod_access" status="obsolete">Allow</directive> or <directive
+ module="mod_access" status="obsolete">Deny</directive> directive occurring in a
+ <directive module="core" type="section">Directory</directive> section or
+ <code>.htaccess</code> file, regardless of the setting of the
+ <directive>Order</directive> directive. For details on the merging
+ of configuration sections, see the documentation on <a
+ href="../sections.html">How Directory, Location and Files sections
+ work</a>.</p>
+</usage>
+
+</directivesynopsis>
+
+</modulesynopsis>
--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<modulesynopsis>
+
+<name>mod_auth</name>
+<description>User authentication using text files</description>
+<status>Obsolete</status>
+<hint>obsolete since 2.0.44</hint>
+<sourcefile>mod_auth.c</sourcefile>
+<identifier>auth_module</identifier>
+<compatibility>Available only in versions up to 2.0.43</compatibility>
+
+<summary>
+ <note type="warning"><title>This module is obsolete!</title>
+ <p>Note, that this module has been marked as obsolete. A bunch
+ of modules was introduced in Apache version 2.0.44 that
+ support the new Authentication/Authorization provider mechnism.</p>
+
+ <p>In order to get the ability of HTTP Basic Authentication, you have
+ to use the <module>mod_auth_basic</module> module that implements
+ the HTTP part. <module>mod_authn_file</module> provides for user
+ authentication based on plain text files. File based group
+ authorization is now done by the <module>mod_authz_groupfile</module>
+ module.</p>
+
+ <p>This document is kept only for historical reasons and no
+ longer maintained.</p>
+ </note>
+
+ <p>This module allows the use of HTTP Basic Authentication to
+ restrict access by looking up users in plain text password and
+ group files. Similar functionality and greater scalability is
+ provided by <module status="obsolete">mod_auth_dbm</module>. HTTP Digest
+ Authentication is provided by
+ <module status="obsolete">mod_auth_digest</module>.</p>
+
+</summary>
+<seealso><directive module="core">Require</directive></seealso>
+<seealso><directive module="core">Satisfy</directive></seealso>
+<seealso><directive module="core">AuthName</directive></seealso>
+<seealso><directive module="core">AuthType</directive></seealso>
+
+<directivesynopsis>
+<name>AuthGroupFile</name>
+<description>Sets the name of a text file containing the list
+of user groups for authentication</description>
+<syntax>AuthGroupFile <var>file-path</var></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>The <directive>AuthGroupFile</directive> directive sets the
+ name of a textual file containing the list of user groups for user
+ authentication. <var>File-path</var> is the path to the group
+ file. If it is not absolute (<em>i.e.</em>, if it doesn't begin
+ with a slash), it is treated as relative to the <directive
+ module="core">ServerRoot</directive>.</p>
+
+ <p>Each line of the group file contains a groupname followed by a
+ colon, followed by the member usernames separated by spaces.
+ Example:</p>
+
+ <example>mygroup: bob joe anne</example>
+
+ <p>Note that searching large text files is <em>very</em>
+ inefficient; <directive
+ module="mod_auth_dbm" status="obsolete">AuthDBMGroupFile</directive> should be used
+ instead.</p>
+
+ <note><title>Security</title>
+ <p>Make sure that the <directive>AuthGroupFile</directive> is
+ stored outside the document tree of the web-server; do <em>not</em>
+ put it in the directory that it protects. Otherwise, clients will
+ be able to download the <directive>AuthGroupFile</directive>.</p>
+ </note>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthUserFile</name>
+<description>Sets the name of a text file containing the list of users and
+passwords for authentication</description>
+<syntax>AuthUserFile <var>file-path</var></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>The <directive>AuthUserFile</directive> directive sets the name
+ of a textual file containing the list of users and passwords for
+ user authentication. <var>File-path</var> is the path to the user
+ file. If it is not absolute (<em>i.e.</em>, if it doesn't begin
+ with a slash), it is treated as relative to the <directive
+ module="core">ServerRoot</directive>.</p>
+
+ <p>Each line of the user file contains a username followed by
+ a colon, followed by the <code>crypt()</code> encrypted
+ password. The behavior of multiple occurrences of the same user is
+ undefined.</p>
+
+ <p>The utility <a href="../programs/htpasswd.html">htpasswd</a>
+ which is installed as part of the binary distribution, or which
+ can be found in <code>src/support</code>, is used to maintain
+ this password file. See the <code>man</code> page for more
+ details. In short:</p>
+
+ <p>Create a password file 'Filename' with 'username' as the
+ initial ID. It will prompt for the password:</p>
+
+ <example>htpasswd -c Filename username</example>
+
+ <p>Add or modify 'username2' in the password file 'Filename':</p>
+
+ <example>htpasswd Filename username2</example>
+
+ <p>Note that searching large text files is <em>very</em>
+ inefficient; <directive
+ module="mod_auth_dbm" status="obsolete">AuthDBMUserFile</directive> should be used
+ instead.</p>
+
+ <note><title>Security</title>
+ <p>Make sure that the <directive>AuthUserFile</directive> is
+ stored outside the document tree of the web-server; do <em>not</em>
+ put it in the directory that it protects. Otherwise, clients will
+ be able to download the <directive>AuthUserFile</directive>.</p>
+ </note>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthAuthoritative</name>
+<description>Sets whether authorization and authentication are
+passed to lower level modules</description>
+<syntax>AuthAuthoritative on|off</syntax>
+<default>AuthAuthoritative on</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <note>This information has not been updated for Apache 2.0, which
+ uses a different system for module ordering.</note>
+
+ <p>Setting the <directive>AuthAuthoritative</directive> directive
+ explicitly to <strong>'off'</strong> allows for both
+ authentication and authorization to be passed on to lower level
+ modules (as defined in the <code>Configuration</code> and
+ <code>modules.c</code> files) if there is <strong>no
+ userID</strong> or <strong>rule</strong> matching the supplied
+ userID. If there is a userID and/or rule specified; the usual
+ password and access checks will be applied and a failure will give
+ an Authorization Required reply.</p>
+
+ <p>So if a userID appears in the database of more than one module;
+ or if a valid <directive module="core">Require</directive>
+ directive applies to more than one module; then the first module
+ will verify the credentials; and no access is passed on;
+ regardless of the AuthAuthoritative setting.</p>
+
+ <p>A common use for this is in conjunction with one of the
+ database modules; such as <module status="obsolete">mod_auth_dbm</module>,
+ <code>mod_auth_msql</code>, and <module status="obsolete">mod_auth_anon</module>.
+ These modules supply the bulk of the user credential checking; but
+ a few (administrator) related accesses fall through to a lower
+ level with a well protected <directive
+ module="mod_auth" status="obsolete">AuthUserFile</directive>.</p>
+
+ <p>By default; control is not passed on; and an unknown userID or
+ rule will result in an Authorization Required reply. Not setting
+ it thus keeps the system secure; and forces an NCSA compliant
+ behaviour.</p>
+
+ <note><title>Security</title> Do consider the implications of
+ allowing a user to allow fall-through in his .htaccess file; and
+ verify that this is really what you want; Generally it is easier
+ to just secure a single .htpasswd file, than it is to secure a
+ database such as mSQL. Make sure that the <directive
+ module="mod_auth" status="obsolete">AuthUserFile</directive> and the <directive
+ module="mod_auth" status="obsolete">AuthGroupFile</directive> are stored outside the
+ document tree of the web-server; do <em>not</em> put them in the
+ directory that they protect. Otherwise, clients will be able to
+ download the <directive module="mod_auth" status="obsolete">AuthUserFile</directive>
+ and the <directive module="mod_auth" status="obsolete">AuthGroupFile</directive>.
+ </note>
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<modulesynopsis>
+
+<name>mod_auth_anon</name>
+<description>Allows "anonymous" user access to authenticated
+ areas</description>
+<status>Obsolete</status>
+<hint>replaced by <module>mod_authn_anon</module> since 2.0.44</hint>
+<sourcefile>mod_auth_anon.c</sourcefile>
+<identifier>auth_anon_module</identifier>
+<compatibility>Available only in versions up to 2.0.43</compatibility>
+
+<summary>
+ <note type="warning"><title>This module is obsolete!</title>
+ <p>Note, that this module has been marked as obsolete. A bunch
+ of modules was introduced in Apache version 2.0.44 that
+ support the new Authentication/Authorization provider mechnism.</p>
+
+ <p>In order to get the same functionality, you have to invoke the
+ <module>mod_authn_anon</module> module now.</p>
+
+ <!-- XXX: I think `AuthBasicProvider anon' comes soon, doesn't it? -->
+ <!--
+ <p>In order to get the same functionality, you have
+ to use the <module>mod_auth_basic</module> module that implements
+ the HTTP part. <module>mod_authn_anon</module> provides for
+ anonymous user authentication.</p>
+ -->
+
+ <p>This document is kept only for historical reasons and no
+ longer maintained.</p>
+ </note>
+
+ <p>This module does access control in a manner similar to
+ anonymous-ftp sites; <em>i.e.</em> have a 'magic' user id
+ 'anonymous' and the email address as a password. These email
+ addresses can be logged.</p>
+
+ <p>Combined with other (database) access control methods, this
+ allows for effective user tracking and customization according
+ to a user profile while still keeping the site open for
+ 'unregistered' users. One advantage of using Auth-based user
+ tracking is that, unlike magic-cookies and funny URL
+ pre/postfixes, it is completely browser independent and it
+ allows users to share URLs.</p>
+</summary>
+
+<section id="example"><title>Example</title>
+
+ <p>The example below (when combined with the Auth directives of a
+ htpasswd-file based (or GDM, mSQL etc.) base access
+ control system allows users in as 'guests' with the following
+ properties:</p>
+
+ <ul>
+ <li>It insists that the user enters a userId.
+ (<code>Anonymous_NoUserId</code>)</li>
+
+ <li>It insists that the user enters a password.
+ (<code>Anonymous_MustGiveEmail</code>)</li>
+
+ <li>The password entered must be a valid email address, ie.
+ contain at least one '@' and a '.'.
+ (<code>Anonymous_VerifyEmail</code>)</li>
+
+ <li>The userID must be one of <code>anonymous guest www test
+ welcome</code> and comparison is <strong>not</strong> case
+ sensitive.</li>
+
+ <li>And the Email addresses entered in the passwd field are
+ logged to the error log file
+ (<code>Anonymous_LogEmail</code>)</li>
+ </ul>
+
+ <p>Excerpt of httpd.conf:</p>
+
+ <example>
+ Anonymous_NoUserId off<br />
+ Anonymous_MustGiveEmail on<br />
+ Anonymous_VerifyEmail on<br />
+ Anonymous_LogEmail on<br />
+ Anonymous anonymous guest www test welcome<br />
+ <br />
+ AuthName "Use 'anonymous' & Email address for guest entry"<br />
+ AuthType basic<br />
+ <br />
+ # An
+ AuthUserFile/AuthDBUserFile/AuthDBMUserFile<br />
+ # directive must be specified, or use<br />
+ # Anonymous_Authoritative for public access.<br />
+ # In the .htaccess for the public directory, add:<br />
+ <Files *><br />
+ <indent>
+ Order Deny,Allow<br />
+ Allow from all<br />
+ <br />
+ Require valid-user<br />
+ </indent>
+ </Files>
+ </example>
+</section>
+
+<directivesynopsis>
+<name>Anonymous</name>
+<description>Specifies userIDs that areallowed access without
+password verification</description>
+<syntax>Anonymous <var>user</var> [<var>user</var>] ...</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>A list of one or more 'magic' userIDs which are allowed
+ access without password verification. The userIDs are space
+ separated. It is possible to use the ' and " quotes to allow a
+ space in a userID as well as the \ escape character.</p>
+
+ <p>Please note that the comparison is
+ <strong>case-IN-sensitive</strong>.<br />
+ I strongly suggest that the magic username
+ '<code>anonymous</code>' is always one of the allowed
+ userIDs.</p>
+
+ <example><title>Example:</title>
+ Anonymous anonymous "Not Registered" 'I don\'t know'
+ </example>
+
+ <p>This would allow the user to enter without password
+ verification by using the userId's 'anonymous',
+ 'AnonyMous','Not Registered' and 'I Don't Know'.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>Anonymous_Authoritative</name>
+<description>Configures if authorization will fall-through
+to other methods</description>
+<syntax>Anonymous_Authoritative on|off</syntax>
+<default>Anonymous_Authoritative off</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>When set 'on', there is no fall-through to other authorization
+ methods. So if a userID does not match the values specified in the
+ <directive module="mod_auth_anon" status="obsolete">Anonymous</directive> directive,
+ access is denied.</p>
+
+ <p>Be sure you know what you are doing when you decide to
+ switch it on. And remember that it is the linking order of the
+ modules (in the Configuration / Make file) which details the
+ order in which the Authorization modules are queried.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>Anonymous_LogEmail</name>
+<description>Sets whether the password entered will be logged in the
+error log</description>
+<syntax>Anonymous_LogEmail on|off</syntax>
+<default>Anonymous_LogEmail on</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>When set <code>on</code>, the default, the 'password' entered
+ (which hopefully contains a sensible email address) is logged in
+ the error log.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>Anonymous_MustGiveEmail</name>
+<description>Specifies whether blank passwords are allowed</description>
+<syntax>Anonymous_MustGiveEmail on|off</syntax>
+<default>Anonymous_MustGiveEmail on</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>Specifies whether the user must specify an email address as
+ the password. This prohibits blank passwords.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>Anonymous_NoUserID</name>
+<description>Sets whether the userID field may be empty</description>
+<syntax>Anonymous_NoUserID on|off</syntax>
+<default>Anonymous_NoUserID off</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>When set <code>on</code>, users can leave the userID (and
+ perhaps the password field) empty. This can be very convenient for
+ MS-Explorer users who can just hit return or click directly on the
+ OK button; which seems a natural reaction.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>Anonymous_VerifyEmail</name>
+<description>Sets whether to check the password field for a correctly
+formatted email address</description>
+<syntax>Anonymous_VerifyEmail on|off</syntax>
+<default>Anonymous_VerifyEmail off</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>When set <code>on</code> the 'password' entered is checked for
+ at least one '@' and a '.' to encourage users to enter valid email
+ addresses (see the above <directive
+ module="mod_auth_anon" status="obsolete">Auth_LogEmail</directive>).</p>
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
\ No newline at end of file
--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<modulesynopsis>
+
+<name>mod_auth_dbm</name>
+<description>Provides for user authentication using DBM
+ files</description>
+<status>Obsolete</status>
+<hint>obsolete since 2.0.44</hint>
+<sourcefile>mod_auth_dbm.c</sourcefile>
+<identifier>auth_dbm_module</identifier>
+<compatibility>Available only in versions up to 2.0.43</compatibility>
+
+<summary>
+ <note type="warning"><title>This module is obsolete!</title>
+ <p>Note, that this module has been marked as obsolete. A bunch
+ of modules was introduced in Apache version 2.0.44 that
+ support the new Authentication/Authorization provider mechnism.</p>
+
+ <p>In order to get the ability of HTTP Basic Authentication, you have
+ to use the <module>mod_auth_basic</module> module that implements
+ the HTTP part. <module>mod_authn_dbm</module> provides for user
+ authentication based on DBM-files. DBM-File based group
+ authorization is now done by the <module>mod_authz_dbm</module>
+ module.</p>
+
+ <p>This document is kept only for historical reasons and no
+ longer maintained.</p>
+ </note>
+
+ <p>This module provides for HTTP Basic Authentication, where
+ the usernames and passwords are stored in DBM type database
+ files. It is an alternative to the plain text password files
+ provided by <module status="obsolete">mod_auth</module>.</p>
+</summary>
+
+<seealso><directive module="core">AuthName</directive></seealso>
+<seealso><directive module="core">AuthType</directive></seealso>
+<seealso><directive module="core">Require</directive></seealso>
+<seealso><directive module="core">Satisfy</directive></seealso>
+
+<directivesynopsis>
+<name>AuthDBMGroupFile</name>
+<description>Sets the name of the database file containing the list
+of user groups for authentication</description>
+<syntax>AuthDBMGroupFile <var>file-path</var></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>The <directive>AuthDBMGroupFile</directive> directive sets the
+ name of a DBM file containing the list of user groups for user
+ authentication. <var>File-path</var> is the absolute path to the
+ group file.</p>
+
+ <p>The group file is keyed on the username. The value for a
+ user is a comma-separated list of the groups to which the users
+ belongs. There must be no whitespace within the value, and it
+ must never contain any colons.</p>
+
+ <p>Security: make sure that the
+ <directive>AuthDBMGroupFile</directive> is stored outside the
+ document tree of the web-server; do <em>not</em> put it in the
+ directory that it protects. Otherwise, clients will be able to
+ download the <directive>AuthDBMGroupFile</directive> unless
+ otherwise protected.</p>
+
+ <p>Combining Group and Password DBM files: In some cases it is
+ easier to manage a single database which contains both the
+ password and group details for each user. This simplifies any
+ support programs that need to be written: they now only have to
+ deal with writing to and locking a single DBM file. This can be
+ accomplished by first setting the group and password files to
+ point to the same DBM:</p>
+
+ <example>
+ AuthDBMGroupFile /www/userbase<br />
+ AuthDBMUserFile /www/userbase
+ </example>
+
+ <p>The key for the single DBM is the username. The value consists
+ of</p>
+
+ <example>
+ <var>Unix Crypt-ed Password</var>:<var>List of Groups</var>[:(ignored)]
+ </example>
+
+ <p>The password section contains the Unix <code>crypt()</code>
+ password as before. This is followed by a colon and the comma
+ separated list of groups. Other data may optionally be left in the
+ DBM file after another colon; it is ignored by the authentication
+ module. This is what www.telescope.org uses for its combined
+ password and group database.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthDBMUserFile</name>
+<description>Sets thename of a database file containing the list of users and
+passwords for authentication</description>
+<syntax>AuthDBMUserFile <var>file-path</var></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>The <directive>AuthDBMUserFile</directive> directive sets the
+ name of a DBM file containing the list of users and passwords for
+ user authentication. <var>File-path</var> is the absolute path to
+ the user file.</p>
+
+ <p>The user file is keyed on the username. The value for a user is
+ the <code>crypt()</code> encrypted password, optionally followed
+ by a colon and arbitrary data. The colon and the data following it
+ will be ignored by the server.</p>
+
+ <p>Security: make sure that the
+ <directive>AuthDBMUserFile</directive> is stored outside the
+ document tree of the web-server; do <em>not</em> put it in the
+ directory that it protects. Otherwise, clients will be able to
+ download the <directive>AuthDBMUserFile</directive>.</p>
+
+ <p>Important compatibility note: The implementation of
+ "dbmopen" in the apache modules reads the string length of the
+ hashed values from the DBM data structures, rather than relying
+ upon the string being NULL-appended. Some applications, such as
+ the Netscape web server, rely upon the string being
+ NULL-appended, so if you are having trouble using DBM files
+ interchangeably between applications this may be a part of the
+ problem.</p>
+
+ <p>A perl script called
+ <a href="../programs/dbmmanage.html">dbmmanage</a> is included with
+ Apache. This program can be used to create and update DBM
+ format password files for use with this module.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthDBMType</name>
+<description>Sets the type of database file that is used to
+store passwords</description>
+<syntax>AuthDBMType default|SDBM|GDBM|NDBM|DB</syntax>
+<default>AuthDBMType default</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+<compatibility>Available in version 2.0.30 and later.</compatibility>
+
+<usage>
+
+<p>Sets the type of database file that is used to store the passwords.
+The default database type is determined at compile time. The
+availability of other types of database files also depends on
+<a href="../install.html#dbm">compile-time settings</a>.</p>
+
+<p>It is crucial that whatever program you use to create your password
+files is configured to use the same type of database.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthDBMAuthoritative</name>
+<description>Sets whether authentication and authorization will be
+passwed on to lower level modules</description>
+<syntax>AuthDBMAuthoritative on|off</syntax>
+<default>AuthDBMAuthoritative on</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+
+<note>This information has not been updated to take into account the
+new module ordering techniques in Apache 2.0</note>
+
+ <p>Setting the <directive>AuthDBMAuthoritative</directive>
+ directive explicitly to <strong>'off'</strong> allows for both
+ authentication and authorization to be passed on to lower level
+ modules (as defined in the <code>Configuration</code> and
+ <code>modules.c</code> file if there is <strong>no userID</strong>
+ or <strong>rule</strong> matching the supplied userID. If there is
+ a userID and/or rule specified; the usual password and access
+ checks will be applied and a failure will give an Authorization
+ Required reply.</p>
+
+ <p>So if a userID appears in the database of more than one module;
+ or if a valid <directive module="core">Require</directive>
+ directive applies to more than one module; then the first module
+ will verify the credentials; and no access is passed on;
+ regardless of the <directive>AuthAuthoritative</directive> setting.</p>
+
+ <p>A common use for this is in conjunction with one of the
+ basic auth modules; such as <module status="obsolete">mod_auth</module>. Whereas this
+ DBM module supplies the bulk of the user credential checking; a
+ few (administrator) related accesses fall through to a lower
+ level with a well protected .htpasswd file.</p>
+
+ <p>By default, control is not passed on and an unknown userID
+ or rule will result in an Authorization Required reply. Not
+ setting it thus keeps the system secure and forces an NCSA
+ compliant behaviour.</p>
+
+ <p>Security: Do consider the implications of allowing a user to
+ allow fall-through in his .htaccess file; and verify that this
+ is really what you want; Generally it is easier to just secure
+ a single .htpasswd file, than it is to secure a database which
+ might have more access interfaces.</p>
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
\ No newline at end of file
--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<modulesynopsis>
+<name>mod_auth_digest</name>
+<description>User authentication using MD5
+ Digest Authentication.</description>
+<status>Obsolete</status>
+<hint>obsolete since 2.0.44</hint>
+<sourcefile>mod_auth_digest.c</sourcefile>
+<identifier>auth_digest_module</identifier>
+<compatibility>Available only in versions up to 2.0.43. The new module
+that unfortunately is also named <module>mod_auth_digest</module>
+includes support for the auth provider mechanism introduced
+in 2.0.44.</compatibility>
+
+<summary>
+ <note type="warning"><title>This module is obsolete!</title>
+ <p>Note, that this module has been marked as obsolete. A bunch
+ of modules was introduced in Apache version 2.0.44 that
+ support the new Authentication/Authorization provider mechnism.</p>
+
+ <p>In order to get the ability of HTTP Digest Authentication, you have
+ to use the new <module>mod_auth_digest</module> module that implements
+ the HTTP part. The user and group data management is provided by the
+ <code>mod_authn_*</code> and <code>mod_authz_*</code> modules. If you
+ want to use your existing user files, have a look at <module
+ >mod_authn_file</module>.</p>
+
+ <p>This document is kept only for historical reasons and no
+ longer maintained.</p>
+ </note>
+
+ <p>This module implements HTTP Digest Authentication. However, it
+ has not been extensively tested and is therefore marked
+ experimental.</p>
+</summary>
+
+<seealso><directive module="core">AuthName</directive></seealso>
+<seealso><directive module="core">AuthType</directive></seealso>
+<seealso><directive module="core">Require</directive></seealso>
+<seealso><directive module="core">Satisfy</directive></seealso>
+
+<section id="using"><title>Using Digest Authentication</title>
+
+ <p>Using MD5 Digest authentication is very simple. Simply set
+ up authentication normally, using "AuthType Digest" and
+ "AuthDigestFile" instead of the normal "AuthType Basic" and
+ "AuthUserFile"; also, replace any "AuthGroupFile" with
+ "AuthDigestGroupFile". Then add a "AuthDigestDomain" directive
+ containing at least the root URI(s) for this protection space.
+ Example:</p>
+
+ <example>
+ <Location /private/><br />
+ <indent>
+ AuthType Digest<br />
+ AuthName "private area"<br />
+ AuthDigestDomain /private/ http://mirror.my.dom/private2/<br />
+ AuthDigestFile /web/auth/.digest_pw<br />
+ Require valid-user<br />
+ </indent>
+ </Location>
+ </example>
+
+ <note><title>Note</title>
+ <p>Digest authentication provides a more secure password system
+ than Basic authentication, but only works with supporting
+ browsers. As of July 2002, the major browsers that support digest
+ authentication are <a href="http://www.opera.com/">Opera</a>, <a
+ href="http://www.microsoft.com/windows/ie/">MS Internet
+ Explorer</a> (fails when used with a query string), <a
+ href="http://www.w3.org/Amaya/">Amaya</a> and <a
+ href="http://www.mozilla.org">Mozilla</a>. Since digest
+ authentication is not as widely implemented as basic
+ authentication, you should use it only in controlled settings.</p>
+ </note>
+</section>
+
+<directivesynopsis>
+<name>AuthDigestFile</name>
+<description>Location of the text file containing the list
+of users and encoded passwords for digest authentication</description>
+<syntax>AuthDigestFile <var>file-path</var></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>The <directive>AuthDigestFile</directive> directive sets the
+ name of a textual file containing the list of users and encoded
+ passwords for digest authentication. <var>File-path</var> is the
+ absolute path to the user file.</p>
+
+ <p>The digest file uses a special format. Files in this format
+ can be created using the <a
+ href="../programs/htdigest.html">htdigest</a> utility found in
+ the support/ subdirectory of the Apache distribution.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthDigestGroupFile</name>
+<description>Name of the text file containing the list of groups
+for digest authentication</description>
+<syntax>AuthDigestGroupFile <var>file-path</var></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>The <directive>AuthDigestGroupFile</directive> directive sets
+ the name of a textual file containing the list of groups and their
+ members (user names). <var>File-path</var> is the absolute path to
+ the group file.</p>
+
+ <p>Each line of the group file contains a groupname followed by
+ a colon, followed by the member usernames separated by spaces.
+ Example:</p>
+
+ <example>mygroup: bob joe anne</example>
+
+ <p>Note that searching large text files is <em>very</em>
+ inefficient.</p>
+
+ <p>Security: make sure that the AuthGroupFile is stored outside
+ the document tree of the web-server; do <em>not</em> put it in
+ the directory that it protects. Otherwise, clients will be able
+ to download the AuthGroupFile.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthDigestQop</name>
+<description>Determines the quality-of-protection to use in digest
+authentication</description>
+<syntax>AuthDigestQop none|auth|auth-int [auth|auth-int]</syntax>
+<default>AuthDigestQop auth</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>The <directive>AuthDigestQop</directive> directive determines
+ the quality-of-protection to use. <code>auth</code> will only do
+ authentication (username/password); <code>auth-int</code> is
+ authentication plus integrity checking (an MD5 hash of the entity
+ is also computed and checked); <code>none</code> will cause the module
+ to use the old RFC-2069 digest algorithm (which does not include
+ integrity checking). Both <code>auth</code> and <code>auth-int</code> may
+ be specified, in which the case the browser will choose which of
+ these to use. <code>none</code> should only be used if the browser for
+ some reason does not like the challenge it receives otherwise.</p>
+
+ <note>
+ <code>auth-int</code> is not implemented yet.
+ </note>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthDigestNonceLifetime</name>
+<description>How long the server nonce is valid</description>
+<syntax>AuthDigestNonceLifetime <var>seconds</var></syntax>
+<default>AuthDigestNonceLifetime 300</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>The <directive>AuthDigestNonceLifetime</directive> directive
+ controls how long the server nonce is valid. When the client
+ contacts the server using an expired nonce the server will send
+ back a 401 with <code>stale=true</code>. If <var>seconds</var> is
+ greater than 0 then it specifies the amount of time for which the
+ nonce is valid; this should probably never be set to less than 10
+ seconds. If <var>seconds</var> is less than 0 then the nonce never
+ expires. <!-- Not implemented yet If <var>seconds</var> is 0 then
+ the nonce may be used exactly once by the client. Note that while
+ one-time-nonces provide higher security against replay attacks,
+ they also have significant performance implications, as the
+ browser cannot pipeline or multiple connections for the
+ requests. Because browsers cannot easily detect that
+ one-time-nonces are being used, this may lead to browsers trying
+ to pipeline requests and receiving 401 responses for all but the
+ first request, requiring the browser to resend the requests. Note
+ also that the protection against reply attacks only makes sense
+ for dynamically generated content and things like POST requests;
+ for static content the attacker may already have the complete
+ response, so one-time-nonces do not make sense here. -->
+ </p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthDigestNonceFormat</name>
+<description>Determines how the nonce is generated</description>
+<syntax>AuthDigestNonceFormat <var>format</var></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p><strong>Not implemented yet.</strong> <!--
+ <P>The AuthDigestNonceFormat directive determines how the nonce is
+ generated.
+ -->
+ </p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthDigestNcCheck</name>
+<description>Enables or disables checking of the nonce-count sent by the
+server</description>
+<syntax>AuthDigestNcCheck On|Off</syntax>
+<default>AuthDigestNcCheck Off</default>
+<contextlist><context>server config</context></contextlist>
+
+<usage>
+ <note>
+ Not implemented yet.
+ </note>
+ <!--
+ <P>The AuthDigestNcCheck directive enables or disables the checking of the
+ nonce-count sent by the server.
+
+ <P>While recommended from a security standpoint, turning this directive
+ On has one important performance implication. To check the nonce-count
+ *all* requests (which have an Authorization header, irrespective of
+ whether they require digest authentication) must be serialized through
+ a critical section. If the server is handling a large number of
+ requests which contain the Authorization header then this may noticeably
+ impact performance.
+ -->
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthDigestAlgorithm</name>
+<description>Selects the algorithm used to calculate the challenge and
+response hases in digest authentication</description>
+<syntax>AuthDigestAlgorithm MD5|MD5-sess</syntax>
+<default>AuthDigestAlgorithm MD5</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>The <directive>AuthDigestAlgorithm</directive> directive
+ selects the algorithm used to calculate the challenge and response
+ hashes.</p>
+
+ <note>
+ <code>MD5-sess</code> is not correctly implemented yet.
+ </note>
+ <!--
+ <P>To use <EM>MD5-sess</EM> you must first code up the
+ <VAR>get_userpw_hash()</VAR> function in <VAR>mod_auth_digest.c</VAR> .
+ -->
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthDigestDomain</name>
+<description>URIs that are in the same protection space for digest
+authentication</description>
+<syntax>AuthDigestDomain <var>URI</var> [<var>URI</var>] ...</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>The <directive>AuthDigestDomain</directive> directive allows
+ you to specify one or more URIs which are in the same protection
+ space (i.e. use the same realm and username/password info). The
+ specified URIs are prefixes, i.e. the client will assume that all
+ URIs "below" these are also protected by the same
+ username/password. The URIs may be either absolute URIs
+ (i.e. inluding a scheme, host, port, etc) or relative URIs.</p>
+
+ <p>This directive <em>should</em> always be specified and
+ contain at least the (set of) root URI(s) for this space.
+ Omitting to do so will cause the client to send the
+ Authorization header for <em>every request</em> sent to this
+ server. Apart from increasing the size of the request, it may
+ also have a detrimental effect on performance if
+ "AuthDigestNcCheck" is on.</p>
+
+ <p>The URIs specified can also point to different servers, in
+ which case clients (which understand this) will then share
+ username/password info across multiple servers without
+ prompting the user each time. </p>
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
+
+
+
<modulefile>perchild.xml</modulefile>
<modulefile>prefork.xml</modulefile>
<modulefile>worker.xml</modulefile>
+
+ <modulefile>obs_mod_access.xml</modulefile>
+ <modulefile>obs_mod_auth.xml</modulefile>
+ <modulefile>obs_mod_auth_anon.xml</modulefile>
+ <modulefile>obs_mod_auth_dbm.xml</modulefile>
+ <modulefile>obs_mod_auth_digest.xml</modulefile>
</modulefilelist>
</category>
projects / apache / commitdiff