this patch tries to take full care of the aaa changes and cleanup the docs
a bit (escpecially mod_auth_digest). Please review.
main changes:
- introduce docs for mod_authn_default, mod_authz_default and
mod_authz_user (not included in the patch, because it's a cvs diff; see
below for full online version)
- fix argument lists of the provider directives
- fix the examples (intended to be better :)
- introduce the AuthDigestShmemSize directive
- remove AuthDigestUser/GroupFile
- mention htdigest in AuthUserFile docs
As usual you'll find all the stuff online at
<http://cvs.apache.org/~nd/manual/mod/> (both xml and html output).
(an impressive list of auth modules *g*)
TIA, nd
--
If God intended people to be naked, they would be born that way.
-- Oscar Wilde
? update.bat
? manual/build
? manual/mod/mod_authn_default.xml
? manual/mod/mod_authz_default.xml
? manual/mod/mod_authz_user.xml
Index: manual/sitemap.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/sitemap.xml,v
retrieving revision 1.15
diff -u -r1.15 sitemap.xml
--- manual/sitemap.xml 5 Dec 2002 17:11:18 -0000 1.15
+++ manual/sitemap.xml 8 Dec 2002 00:09:49 -0000
@@ -135,9 +135,12 @@
<modulefile>mod_authn_anon.xml</modulefile>
<modulefile>mod_authn_dbm.xml</modulefile>
<modulefile>mod_authn_file.xml</modulefile>
+ <modulefile>mod_authn_default.xml</modulefile>
<modulefile>mod_authz_dbm.xml</modulefile>
+ <modulefile>mod_authz_default.xml</modulefile>
<modulefile>mod_authz_groupfile.xml</modulefile>
<modulefile>mod_authz_host.xml</modulefile>
+ <modulefile>mod_authz_user.xml</modulefile>
<modulefile>mod_auth_ldap.xml</modulefile>
<modulefile>mod_autoindex.xml</modulefile>
<modulefile>mod_cache.xml</modulefile>
Index: manual/mod/mod_auth_basic.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_auth_basic.xml,v
retrieving revision 1.4
diff -u -r1.4 mod_auth_basic.xml
--- manual/mod/mod_auth_basic.xml 5 Dec 2002 17:04:11 -0000 1.4
+++ manual/mod/mod_auth_basic.xml 8 Dec 2002 00:09:50 -0000
@@ -11,12 +11,10 @@
<compatibility>Available in Apache 2.1 and later</compatibility>
<summary>
-
<p>This module allows the use of HTTP Basic Authentication to
restrict access by looking up users in the given providers.
HTTP Digest Authentication is provided by
<module>mod_auth_digest</module>.</p>
-
</summary>
<seealso><directive module="core">AuthName</directive></seealso>
<seealso><directive module="core">AuthType</directive></seealso>
@@ -24,43 +22,52 @@
<directivesynopsis>
<name>AuthBasicProvider</name>
<description>Sets the authentication provider(s) for this
location</description>
-<syntax>AuthBasicProvider <em>provider-name</em></syntax>
-<contextlist>
- <context>directory</context>
- <context>.htaccess</context>
-</contextlist>
-<override>AuthConfig</override>
+<syntax>AuthBasicProvider On|Off|<var>provider-name</var>
+[<var>provider-name</var>] ...</syntax>
+<default>AuthBasicProvider On</default>
+<contextlist><context>directory</context></contextlist>
<usage>
<p>The <directive>AuthBasicProvider</directive> directive sets
- which provider is used to authenticate the users for this location.</p>
+ which provider is used to authenticate the users for this location.
+ Setting the value to <code>On</code> will choose the default provider
+ (<code>file</code>). Since the <code>file</code> provider is implemented
+ by the <module>mod_authn_file</module> module, you have to make sure,
+ that the module is present in the server.</p>
+
+ <example><title>Example</title>
+ <Location /secure><br />
+ <indent>
+ AuthBasicProvider dbm<br />
+ AuthDBMType SDBM<br />
+ AuthDBMUserFile /www/etc/dbmpasswd<br />
+ Require valid-user<br />
+ </indent>
+ </Location>
+ </example>
- <p>See <module>mod_authn_dbm</module>, <module>mod_authn_file</module>
+ <p>See <module>mod_authn_dbm</module> and <module>mod_authn_file</module>
for providers.</p>
-
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthBasicAuthoritative</name>
-<description>Sets whether authorization and authentication are
-passed to lower level modules</description>
-<syntax>AuthBasicAuthoritative on|off</syntax>
-<default>AuthBasicAuthoritative on</default>
-<contextlist>
- <context>directory</context>
- <context>.htaccess</context>
+<description>Sets whether authorization and authentication are passed to
+lower level modules</description>
+<syntax>AuthBasicAuthoritative On|Off</syntax>
+<default>AuthBasicAuthoritative On</default>
+<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>Setting the <directive>AuthBasicAuthoritative</directive> directive
- explicitly to <strong>'off'</strong> allows for both
+ explicitly to <code>Off</code> 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
+ modules (as defined in the <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>
@@ -70,11 +77,10 @@
will verify the credentials; and no access is passed on;
regardless of the AuthAuthoritative setting.</p>
- <p>By default; control is not passed on; and an unknown userID or
+ <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
+ it thus keeps the system secure and forces an NCSA compliant
behaviour.</p>
-
</usage>
</directivesynopsis>
Index: manual/mod/mod_auth_digest.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_auth_digest.xml,v
retrieving revision 1.6
diff -u -r1.6 mod_auth_digest.xml
--- manual/mod/mod_auth_digest.xml 2 Dec 2002 21:58:34 -0000 1.6
+++ manual/mod/mod_auth_digest.xml 8 Dec 2002 00:09:52 -0000
@@ -11,7 +11,7 @@
<identifier>auth_digest_module</identifier>
<summary>
- <p>This module implements HTTP Digest Authentication. However, it
+ <p>This module implements HTTP Digest Authentication. However, it
has not been extensively tested and is therefore marked
experimental.</p>
</summary>
@@ -24,20 +24,26 @@
<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>
+ up authentication normally, using <code>AuthType Digest</code> and
+ <directive module="mod_auth_digest">AuthDigestProvider</directive>
+ instead of the normal <code>AuthType Basic</code> and
+ <directive module="mod_auth_basic">AuthBasicProvider</directive>.
+ Then add a <directive module="mod_auth_digest"
+ >AuthDigestDomain</directive> directive containing at least the root
+ URI(s) for this protection space.</p>
- <example>
+ <p>Appropriate user (text) files can be created using the
+ <a href="../programs/htdigest.html">htdigest</a> tool.</p>
+
+ <example><title>Example:</title>
<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 />
+ <br />
+ AuthDigestProvider file<br />
+ AuthUserFile /web/auth/.digest_pw<br />
Require valid-user<br />
</indent>
</Location>
@@ -46,67 +52,37 @@
<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
+ browsers. As of November 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
+ href="http://www.w3.org/Amaya/";>Amaya</a>, <a
+ href="http://www.mozilla.org";>Mozilla</a> and <a
+ href="http://channels.netscape.com/ns/browsers/download.jsp";
+ >Netscape</a> since version 7. 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>
+<name>AuthDigestProvider</name>
+<description>Sets the authentication provider(s) for this
location</description>
+<syntax>AuthDigestProvider On|Off|<var>provider-name</var>
+[<var>provider-name</var>] ...</syntax>
+<default>AuthBasicProvider On</default>
+<contextlist><context>directory</context></contextlist>
<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>
+ <p>The <directive>AuthDigestProvider</directive> directive sets
+ which provider is used to authenticate the users for this location.
+ Setting the value to <code>On</code> will choose the default provider
+ (<code>file</code>). Since the <code>file</code> provider is implemented
+ by the <module>mod_authn_file</module> module, you have to make sure,
+ that the module is present in the server.</p>
-<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>
+ <p>See <module>mod_authn_dbm</module> and <module>mod_authn_file</module>
+ for providers.</p>
</usage>
</directivesynopsis>
@@ -122,8 +98,8 @@
<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
+ the <dfn>quality-of-protection</dfn> 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
@@ -155,7 +131,7 @@
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
+ 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
@@ -181,11 +157,9 @@
<override>AuthConfig</override>
<usage>
- <p><strong>Not implemented yet.</strong> <!--
- <P>The AuthDigestNonceFormat directive determines how the nonce is
- generated.
- -->
- </p>
+ <note>Not implemented yet.</note>
+ <!-- The AuthDigestNonceFormat directive determines how the nonce is
+ generated. -->
</usage>
</directivesynopsis>
@@ -202,16 +176,16 @@
Not implemented yet.
</note>
<!--
- <P>The AuthDigestNcCheck directive enables or disables the
checking of the
- nonce-count sent by the server.
+ <p>The AuthDigestNcCheck directive enables or disables the checking of the
+ nonce-count sent by the server.</p>
- <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.
+ <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.</p>
-->
</usage>
</directivesynopsis>
@@ -235,8 +209,9 @@
<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> .
+ <p>To use <code>MD5-sess</code> you must first code up the
+ <code>get_userpw_hash()</code> function in
+ <code>mod_auth_digest.c</code>.</p>
-->
</usage>
</directivesynopsis>
@@ -271,6 +246,38 @@
which case clients (which understand this) will then share
username/password info across multiple servers without
prompting the user each time. </p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthDigestShmemSize</name>
+<description>The amount of shared memory to allocate for keeping track
+of clients</description>
+<syntax>AuthDigestShmemSize <var>size</var></syntax>
+<default>AuthDigestShmemSize 1000</default>
+<contextlist><context>server config</context></contextlist>
+
+<usage>
+ <p>The <directive>AuthDigestShmemSize</directive> directive defines
+ the amount of shared memory, that will be allocated at the server
+ startup for keeping track of clients. Note that the shared memory
+ segment cannot be set less than the space that is neccessary for
+ tracking at least <em>one</em> client. This value is dependant on your
+ system. If you want to find out the exact value, you may simply
+ set <directive>AuthDigestShmemSize</directive> to the value of
+ <code>0</code> and read the error message after trying to start the
+ server.</p>
+
+ <p>The <var>size</var> is normally expressed in Bytes, but you
+ may let the number follow a <code>K</code> or an <code>M</code> to
+ express your value as KBytes or MBytes. For example, the following
+ directives are all equivalent:</p>
+
+ <example>
+ AuthDigestShmemSize 1048576<br />
+ AuthDigestShmemSize 1024K<br />
+ AuthDigestShmemSize 1M<br />
+ </example>
</usage>
</directivesynopsis>
Index: manual/mod/mod_authn_anon.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_authn_anon.xml,v
retrieving revision 1.3
diff -u -r1.3 mod_authn_anon.xml
--- manual/mod/mod_authn_anon.xml 5 Dec 2002 17:04:11 -0000 1.3
+++ manual/mod/mod_authn_anon.xml 8 Dec 2002 00:09:53 -0000
@@ -26,23 +26,25 @@
allows users to share URLs.</p>
</summary>
-<section><title>Example</title>
-
+<section id="example"><title>Example</title>
<p>The example below (when combined with the Auth directives of a
- htpasswd-file based (or GDM, mSQL <em>etc.</em>) base access
+ htpasswd-file based (or GDBM, mSQL <em>etc.</em>) 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>
+ (<directive module="mod_authn_anon"
+ >Anonymous_NoUserId</directive>)</li>
<li>It insists that the user enters a password.
- (<code>Anonymous_MustGiveEmail</code>)</li>
+ (<directive module="mod_authn_anon"
+ >Anonymous_MustGiveEmail</directive>)</li>
- <li>The password entered must be a valid email address, ie.
+ <li>The password entered must be a valid email address, <em>i.e.</em>
contain at least one '@' and a '.'.
- (<code>Anonymous_VerifyEmail</code>)</li>
+ (<directive module="mod_authn_anon"
+ >Anonymous_VerifyEmail</directive>)</li>
<li>The userID must be one of <code>anonymous guest www test
welcome</code> and comparison is <strong>not</strong> case
@@ -50,41 +52,41 @@
<li>And the Email addresses entered in the passwd field are
logged to the error log file
- (<code>Anonymous_LogEmail</code>)</li>
+ (<directive module="mod_authn_anon"
+ >Anonymous_LogEmail</directive>)</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/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 />
- Order Deny,Allow<br />
- Allow from all<br />
-<br />
- Require valid-user<br />
- </Files><br />
-</example>
+ <example><title>Excerpt of httpd.conf:</title>
+ 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/AuthDBMUserFile<br />
+ # directive must be specified, or use<br />
+ # Anonymous_Authoritative for public access.<br />
+ # In the .htaccess for the public directory, add:<br />
+ <!-- XXX: what is the <Files> container for? -->
+ <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 <em>user</em> [<em>user</em>] ...</syntax>
+<syntax>Anonymous <var>user</var> [<var>user</var>] ...</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
@@ -97,16 +99,17 @@
<p>Please note that the comparison is
<strong>case-IN-sensitive</strong>.<br />
- I strongly suggest that the magic username
+ It's strongly recommended that the magic username
'<code>anonymous</code>' is always one of the allowed
userIDs.</p>
- <p>Example:</p>
-<example>Anonymous anonymous "Not Registered" 'I don\'t know'</example>
+ <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>
+ verification by using the userIDs "anonymous",
+ "AnonyMous", "Not Registered" and "I Don't Know".</p>
</usage>
</directivesynopsis>
@@ -114,22 +117,22 @@
<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>
+<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_authn_anon">Anonymous</directive> directive,
- access is denied.</p>
+ <p>When set <code>On</code>, there is no fall-through to other
+ authentication methods. So if a userID does not match the values
+ specified in the <directive module="mod_authn_anon">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>
+ switch it on. And remember that it is the hooking order of the
+ modules (in the <code>module.c</code> files) which details the
+ order in which the Authentication modules are queried.</p>
</usage>
</directivesynopsis>
@@ -137,14 +140,14 @@
<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>
+<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
+ <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>
@@ -153,8 +156,8 @@
<directivesynopsis>
<name>Anonymous_MustGiveEmail</name>
<description>Specifies whether blank passwords are allowed</description>
-<syntax>Anonymous_MustGiveEmail on|off</syntax>
-<default>Anonymous_MustGiveEmail on</default>
+<syntax>Anonymous_MustGiveEmail On|Off</syntax>
+<default>Anonymous_MustGiveEmail On</default>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
@@ -168,14 +171,14 @@
<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>
+<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
+ <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>
@@ -186,17 +189,17 @@
<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>
+<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
+ <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_authn_anon">Auth_LogEmail</directive>).</p>
+ module="mod_authn_anon">Anonymous_LogEmail</directive>).</p>
</usage>
</directivesynopsis>
Index: manual/mod/mod_authn_dbm.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_authn_dbm.xml,v
retrieving revision 1.4
diff -u -r1.4 mod_authn_dbm.xml
--- manual/mod/mod_authn_dbm.xml 5 Dec 2002 17:04:11 -0000 1.4
+++ manual/mod/mod_authn_dbm.xml 8 Dec 2002 00:09:53 -0000
@@ -13,14 +13,15 @@
<summary>
<p>This module provides authentication front-ends such as
<module>mod_auth_digest</module> and <module>mod_auth_basic</module>
- to authenticate users by looking up users in plain text password files.
- Similar functionality is provided by <module>mod_authn_file</module>.</p>
+ to authenticate users by looking up users in <dfn>dbm</dfn> password
+ files. Similar functionality is provided by
+ <module>mod_authn_file</module>.</p>
<p>When using <module>mod_auth_basic</module> or
<module>mod_auth_digest</module>, this module is invoked via the
<directive module="mod_auth_basic">AuthBasicProvider</directive> or
<directive module="mod_auth_digest">AuthDigestProvider</directive>
- with the 'dbm' value.</p>
+ with the <code>dbm</code> value.</p>
</summary>
<seealso><directive module="core">AuthName</directive></seealso>
@@ -36,17 +37,15 @@
<name>AuthDBMUserFile</name>
<description>Sets the name of a database file containing the list of users and
passwords for authentication</description>
-<syntax>AuthDBMUserFile <em>file-path</em></syntax>
-<contextlist>
- <context>directory</context>
- <context>.htaccess</context>
+<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. <em>File-path</em> is the absolute path to
+ 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
@@ -61,8 +60,8 @@
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
+ <code>dbmopen</code> 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
@@ -82,22 +81,18 @@
store passwords</description>
<syntax>AuthDBMType default|SDBM|GDBM|NDBM|DB</syntax>
<default>AuthDBMType default</default>
-<contextlist>
- <context>directory</context>
- <context>.htaccess</context>
+<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>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>
+ <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>
Index: manual/mod/mod_authn_file.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_authn_file.xml,v
retrieving revision 1.4
diff -u -r1.4 mod_authn_file.xml
--- manual/mod/mod_authn_file.xml 5 Dec 2002 17:04:11 -0000 1.4
+++ manual/mod/mod_authn_file.xml 8 Dec 2002 00:09:54 -0000
@@ -11,7 +11,6 @@
<compatibility>Available in Apache 2.1 and later</compatibility>
<summary>
-
<p>This module provides authentication front-ends such as
<module>mod_auth_digest</module> and <module>mod_auth_basic</module>
to authenticate users by looking up users in plain text password files.
@@ -21,65 +20,77 @@
<module>mod_auth_digest</module>, this module is invoked via the
<directive module="mod_auth_basic">AuthBasicProvider</directive> or
<directive module="mod_auth_digest">AuthDigestProvider</directive>
- with the 'file' value.</p>
-
+ with the <code>file</code> value.</p>
</summary>
-<seealso><directive module="core">AuthName</directive></seealso>
-<seealso><directive module="core">AuthType</directive></seealso>
<seealso>
<directive module="mod_auth_basic">AuthBasicProvider</directive>
</seealso>
<seealso>
<directive module="mod_auth_digest">AuthDigestProvider</directive>
</seealso>
+<seealso><a href="../programs/htpasswd.html">htpasswd</a></seealso>
+<seealso><a href="../programs/htdigest.html">htdigest</a></seealso>
<directivesynopsis>
<name>AuthUserFile</name>
<description>Sets the name of a text file containing the list of users and
passwords for authentication</description>
-<syntax>AuthUserFile <em>file-path</em></syntax>
-<contextlist>
- <context>directory</context>
- <context>.htaccess</context>
+<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. <em>File-path</em> 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>
+ user authentication. <var>File-path</var> is the path to the user
+ file. If it is not absolute, 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>
+ a colon, followed by the encrypted password. If the same user
+ ID is defined multiple times, <module>mod_authn_file</module> will
+ use the first occurrence to verify the password.</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>
+ the password file for <em>HTTP Basic Authentication</em>. See the
+ <a href="../programs/htpasswd.html">man page</a> for more details.
+ In short:</p>
+
+ <p>Create a password file <code>Filename</code> with
+ <code>username</code> as the initial ID. It will prompt for
+ the password:</p>
+
+ <example>
+ htpasswd -c Filename username
+ </example>
+
+ <p>Add or modify <code>username2</code> in the password file
+ <code>Filename</code>:</p>
+
+ <example>
+ htpasswd Filename username2
+ </example>
<p>Note that searching large text files is <em>very</em>
inefficient; <directive
module="mod_authn_dbm">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>
+ <p>If you are using <em>HTTP Digest Authentication</em>, the <a
+ href="../programs/htpasswd.html">htpasswd</a> tool is not sufficient.
+ You have to use <a href="../programs/htdigest.html">htdigest</a>
+ instead. Note that you cannot mix user data for Digest Authentication
+ and Basic Authentication within the same file.</p>
+
+ <note type="warning"><title>Security</title>
+ <p>Make sure that the <directive>AuthUserFile</directive> is
+ stored outside the document tree of the web-server. Do
+ <strong>not</strong> put it in the directory that it protects.
+ Otherwise, clients may be able to download the
+ <directive>AuthUserFile</directive>.</p>
</note>
</usage>
</directivesynopsis>
Index: manual/mod/mod_authz_dbm.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_authz_dbm.xml,v
retrieving revision 1.3
diff -u -r1.3 mod_authz_dbm.xml
--- manual/mod/mod_authz_dbm.xml 5 Dec 2002 17:04:11 -0000 1.3
+++ manual/mod/mod_authz_dbm.xml 8 Dec 2002 00:09:55 -0000
@@ -24,7 +24,7 @@
<name>AuthDBMGroupFile</name>
<description>Sets the name of the database file containing the list
of user groups for authentication</description>
-<syntax>AuthDBMGroupFile <em>file-path</em></syntax>
+<syntax>AuthDBMGroupFile <var>file-path</var></syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
@@ -32,7 +32,7 @@
<usage>
<p>The <directive>AuthDBMGroupFile</directive> directive sets the
name of a DBM file containing the list of user groups for user
- authentication. <em>File-path</em> is the absolute path to the
+ 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
@@ -40,12 +40,14 @@
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>
+ <note type="warning"><title>Security</title>
+ <p>Make sure that the <directive>AuthDBMGroupFile</directive> is
+ stored outside the document tree of the web-server. Do
+ <strong>not</strong> put it in the directory that it protects.
+ Otherwise, clients will be able to download the
+ <directive>AuthDBMGroupFile</directive> unless otherwise
+ protected.</p>
+ </note>
<p>Combining Group and Password DBM files: In some cases it is
easier to manage a single database which contains both the
@@ -55,18 +57,19 @@
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>
+ <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>Unix Crypt-ed Password : List of Groups [ : (ignored)
- ]</example>
+ <example>
+ Encrypted Password : List of Groups [ : (ignored) ]
+ </example>
- <p>The password section contains the Unix <code>crypt()</code>
+ <p>The password section contains the encrypted
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
@@ -81,47 +84,39 @@
store passwords</description>
<syntax>AuthzDBMType default|SDBM|GDBM|NDBM|DB</syntax>
<default>AuthzDBMType default</default>
-<contextlist>
- <context>directory</context>
- <context>.htaccess</context>
+<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>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>
+ <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>AuthzDBMAuthoritative</name>
-<description>Sets whether authorization will be passed on to lower level
modules</description>
-<syntax>AuthzDBMAuthoritative on|off</syntax>
-<default>AuthzDBMAuthoritative on</default>
-<contextlist>
- <context>directory</context>
- <context>.htaccess</context>
+<description>Sets whether authorization will be passed on to lower level
+modules</description>
+<syntax>AuthzDBMAuthoritative On|Off</syntax>
+<default>AuthzDBMAuthoritative On</default>
+<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
-
<p>Setting the <directive>AuthzDBMAuthoritative</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>
+ directive explicitly to <code>Off</code> allows group authorization
+ to be passed on to lower level modules (as defined in the
+ <code>modules.c</code> file) if there is no group found
+ for the the supplied userID. If there are any groups
+ specified, the usual checks will be applied and a failure will
+ give an Authentication 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>
@@ -130,21 +125,24 @@
regardless of the <directive>AuthAuthoritative</directive> setting.</p>
<p>A common use for this is in conjunction with one of the
- auth providers; such as <module>mod_authn_file</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>
+ auth providers; such as <module>mod_authn_dbm</module> or
+ <module>mod_authn_file</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
+ <code>.htpasswd</code> file.</p>
- <p>By default, control is not passed on and an unknown userID
- or rule will result in an Authorization Required reply. Not
+ <p>By default, control is not passed on and an unknown group
+ will result in an Authentication 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>
+ <note type="warning"><title>Security</title>
+ <p>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 <code>.htpasswd</code> file, than it is to secure a
+ database which might have more access interfaces.</p>
+ </note>
</usage>
</directivesynopsis>
Index: manual/mod/mod_authz_groupfile.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_authz_groupfile.xml,v
retrieving revision 1.3
diff -u -r1.3 mod_authz_groupfile.xml
--- manual/mod/mod_authz_groupfile.xml 5 Dec 2002 17:04:11 -0000 1.3
+++ manual/mod/mod_authz_groupfile.xml 8 Dec 2002 00:09:55 -0000
@@ -5,16 +5,16 @@
<name>mod_authz_groupfile</name>
<description>Group authorization using plaintext files</description>
-<status>Extension</status>
+<status>Base</status>
<sourcefile>mod_authz_groupfile.c</sourcefile>
<identifier>authz_groupfile_module</identifier>
<compatibility>Available in Apache 2.1 and later</compatibility>
<summary>
<p>This module provides authorization capabilities so that
- authenticated users can be allowed or denied access to portions
- of the web site by group membership. Similar functionality is
- provided by <module>mod_authz_dbm</module>.</p>
+ authenticated users can be allowed or denied access to portions
+ of the web site by group membership. Similar functionality is
+ provided by <module>mod_authz_dbm</module>.</p>
</summary>
<seealso><directive module="core">Require</directive></seealso>
@@ -24,79 +24,67 @@
<name>AuthGroupFile</name>
<description>Sets the name of a text file containing the list
of user groups for authentication</description>
-<syntax>AuthGroupFile <em>file-path</em></syntax>
-<contextlist>
- <context>directory</context>
- <context>.htaccess</context>
+<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. <em>File-path</em> 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
+ authentication. <var>File-path</var> is the path to the group
+ file. If it is not absolute, 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>
+ colon, followed by the member usernames separated by spaces.</p>
- <example>mygroup: bob joe anne</example>
+ <example><title>Example:</title>
+ mygroup: bob joe anne
+ </example>
<p>Note that searching large text files is <em>very</em>
- inefficient; <directive
- module="mod_authz_dbm">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>
+ inefficient; <directive module="mod_authz_dbm"
+ >AuthDBMGroupFile</directive> should be used instead.</p>
+
+ <note type="warning"><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 may
+ be able to download the <directive>AuthGroupFile</directive>.</p>
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthzGroupFileAuthoritative</name>
-<description>Sets whether authorization will be passed on to lower level
modules</description>
-<syntax>AuthzGroupFileAuthoritative on|off</syntax>
-<default>AuthzGroupFileAuthoritative on</default>
-<contextlist>
- <context>directory</context>
- <context>.htaccess</context>
+<description>Sets whether authorization will be passed on to lower level
+modules</description>
+<syntax>AuthzGroupFileAuthoritative On|Off</syntax>
+<default>AuthzGroupFileAuthoritative On</default>
+<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
-
<p>Setting the <directive>AuthzGroupFileAuthoritative</directive>
- directive explicitly to <strong>'off'</strong> allows for
- 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 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>AuthzGroupFileAuthoritative</directive>
- setting.</p>
+ directive explicitly to <code>Off</code> allows for
+ group authorization to be passed on to lower level modules (as defined
+ in the <code>modules.c</code> files) if there is <strong>no
+ group</strong> matching the supplied userID.</p>
- <p>By default, control is not passed on and an unknown userID
- or rule will result in an Authorization Required reply. Not
+ <p>By default, control is not passed on and an unknown group
+ will result in an Authentication 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>
+ <note type="warning"><title>Security</title>
+ <p>Do consider the implications of allowing a user to
+ allow fall-through in his <code>.htaccess</code> file; and verify
+ that this is really what you want; Generally it is easier to just
+ secure a single <code>.htpasswd</code> file, than it is to secure
+ a database which might have more access interfaces.</p>
+ </note>
</usage>
</directivesynopsis>
Index: manual/mod/mod_authz_host.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_authz_host.xml,v
retrieving revision 1.3
diff -u -r1.3 mod_authz_host.xml
--- manual/mod/mod_authz_host.xml 5 Dec 2002 17:04:11 -0000 1.3
+++ manual/mod/mod_authz_host.xml 8 Dec 2002 00:09:57 -0000
@@ -4,10 +4,8 @@
<modulesynopsis>
<name>mod_authz_host</name>
-
<description>Group authorizations based on host (name or IP
address)</description>
-
<status>Base</status>
<sourcefile>mod_authz_host.c</sourcefile>
<identifier>authz_host_module</identifier>
@@ -50,18 +48,15 @@
<directivesynopsis>
<name>Allow</name>
-
<description>Controls which hosts can access an area of the
server</description>
-<syntax> Allow from
- all|<em>host</em>|env=<em>env-variable</em>
- [<em>host</em>|env=<em>env-variable</em>] ...</syntax>
+<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
@@ -81,39 +76,53 @@
<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
+ <dd>
+ <example><title>Example:</title>
+ Allow from apache.org
+ </example>
+ <p>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>
+ directive.</p></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>
+ <dd>
+ <example><title>Example:</title>
+ Allow from 10.1.2.3
+ </example>
+ <p>An IP address of a host allowed access</p></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>
+ <dd>
+ <example><title>Example:</title>
+ Allow from 10.1
+ </example>
+ <p>The first 1 to 3 bytes of an IP address, for subnet
+ restriction.</p></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>
+ <dd>
+ <example><title>Example:</title>
+ Allow from 10.1.0.0/255.255.0.0
+ </example>
+ <p>A network a.b.c.d, and a netmask w.x.y.z. For more
+ fine-grained subnet restriction.</p></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>
+ <dd>
+ <example><title>Example:</title>
+ Allow from 10.1.0.0/16
+ </example>
+ <p>Similar to the previous case, except the netmask consists of
+ nnn high-order 1 bits.</p></dd>
</dl>
<p>Note that the last three examples above match exactly the
@@ -131,43 +140,39 @@
<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=</code><em>env-variable</em> is specified, then the request is
- allowed access if the environment variable <em>env-variable</em>
+ 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
+ <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 />
- Order Deny,Allow<br />
- Deny from all<br />
- Allow from env=let_me_in<br />
-</Directory>
-</example>
+ <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|<em>host</em>|env=<em>env-variable</em>
- [<em>host</em>|env=<em>env-variable</em>] ...</syntax>
+<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>
@@ -179,43 +184,38 @@
identical to the arguments for the <directive
module="mod_authz_host">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 <em>ordering</em></syntax>
+<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_authz_host">Allow</directive> and <directive
module="mod_authz_host">Deny</directive> directives are evaluated.
- <em>Ordering</em> is one of</p>
+ <var>Ordering</var> is one of</p>
<dl>
- <dt>Deny,Allow</dt>
+ <dt><code>Deny,Allow</code></dt>
<dd>The <directive module="mod_authz_host">Deny</directive> directives
are evaluated before the <directive
module="mod_authz_host">Allow</directive> directives. Access is
- allowed by default. Any client which does not match a
+ allowed by default. Any client which does not match a
<directive module="mod_authz_host">Deny</directive> directive or does
match an <directive module="mod_authz_host">Allow</directive>
directive will be allowed access to the server.</dd>
- <dt>Allow,Deny</dt>
+ <dt><code>Allow,Deny</code></dt>
<dd>The <directive module="mod_authz_host">Allow</directive>
directives are evaluated before the <directive
@@ -225,7 +225,7 @@
<directive module="mod_authz_host">Deny</directive> directive will be
denied access to the server.</dd>
- <dt>Mutual-failure</dt>
+ <dt><code>Mutual-failure</code></dt>
<dd>Only those hosts which appear on the <directive
module="mod_authz_host">Allow</directive> list and do not appear on
@@ -235,7 +235,7 @@
configuration.</dd>
</dl>
- <p>Keywords may only be separated by a comma; no whitespace is
+ <p>Keywords may only be separated by a comma; <em>no whitespace</em> is
allowed between them. Note that in all cases every <directive
module="mod_authz_host">Allow</directive> and <directive
module="mod_authz_host">Deny</directive> statement is evaluated.</p>
@@ -243,11 +243,11 @@
<p>In the following example, all hosts in the apache.org domain
are allowed access; all other hosts are denied access.</p>
-<example>
+ <example>
Order Deny,Allow<br />
Deny from all<br />
- Allow from apache.org<br />
-</example>
+ 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
@@ -255,11 +255,11 @@
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<br />
-</example>
+ <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
@@ -275,13 +275,15 @@
access to a part of the server even in the absence of accompanying
<directive module="mod_authz_host">Allow</directive> and <directive
module="mod_authz_host">Deny</directive> directives because of its effect
- on the default access state. For example,</p>
+ on the default access state. For example,</p>
-<example>
+ <example>
<Directory /www><br />
- Order Allow,Deny<br />
+ <indent>
+ Order Allow,Deny<br />
+ </indent>
</Directory>
-</example>
+ </example>
<p>will deny all access to the <code>/www</code> directory
because the default access state will be set to
@@ -303,7 +305,6 @@
href="../sections.html">How Directory, Location and Files sections
work</a>.</p>
</usage>
-
</directivesynopsis>
</modulesynopsis>
