--- /dev/null
+<?xml version="1.0"?>\r
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">\r
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>\r
+<!-- $LastChangedRevision: 327999 $ -->\r
+\r
+<!--\r
+ Copyright 2002-2005 The Apache Software Foundation or its licensors, as\r
+ applicable.\r
+\r
+ Licensed under the Apache License, Version 2.0 (the "License");\r
+ you may not use this file except in compliance with the License.\r
+ You may obtain a copy of the License at\r
+\r
+ http://www.apache.org/licenses/LICENSE-2.0\r
+\r
+ Unless required by applicable law or agreed to in writing, software\r
+ distributed under the License is distributed on an "AS IS" BASIS,\r
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\r
+ See the License for the specific language governing permissions and\r
+ limitations under the License.\r
+-->\r
+\r
+<modulesynopsis metafile="mod_access_compat.xml.meta">\r
+\r
+<name>mod_access_compat</name> \r
+<description>Group authorizations based on host (name or IP\r
+address)</description>\r
+<status>Extension</status>\r
+<sourcefile>mod_access_compat.c</sourcefile>\r
+<identifier>access_compat_module</identifier>\r
+<compatibility>Available in Apache 2.3 as a compatibility module with \r
+previous versions of Apache 2.x. The directives provided by this module\r
+have been deprecated by the new authz refactoring. Please see \r
+<module>mod_authz_host</module></compatibility>\r
+\r
+<summary>\r
+ <p>The directives provided by <module>mod_access_compat</module> are\r
+ used in <directive module="core" type="section">Directory</directive>,\r
+ <directive module="core" type="section">Files</directive>, and\r
+ <directive module="core" type="section">Location</directive> sections\r
+ as well as <code><a href="core.html#accessfilename">.htaccess</a>\r
+ </code> files to control access to particular parts of the server.\r
+ Access can be controlled based on the client hostname, IP address, or\r
+ other characteristics of the client request, as captured in <a\r
+ href="../env.html">environment variables</a>. The <directive\r
+ module="mod_access_compat">Allow</directive> and <directive\r
+ module="mod_access_compat">Deny</directive> directives are used to\r
+ specify which clients are or are not allowed access to the server,\r
+ while the <directive module="mod_access_compat">Order</directive>\r
+ directive sets the default access state, and configures how the\r
+ <directive module="mod_access_compat">Allow</directive> and <directive\r
+ module="mod_access_compat">Deny</directive> directives interact with each\r
+ other.</p>\r
+\r
+ <p>Both host-based access restrictions and password-based\r
+ authentication may be implemented simultaneously. In that case,\r
+ the <directive module="core">Satisfy</directive> directive is used\r
+ to determine how the two sets of restrictions interact.</p>\r
+\r
+ <note type="warning"><title>Note</title>\r
+ <p>The directives provided by <module>mod_access_compat</module> have\r
+ been deprecated by the new authz refactoring. Please see \r
+ <module>mod_authz_host</module>. The module \r
+ <module>mod_authz_default</module> must also be loaded to provide for\r
+ default authorization handling.</p>\r
+ </note>\r
+\r
+ <p>In general, access restriction directives apply to all\r
+ access methods (<code>GET</code>, <code>PUT</code>,\r
+ <code>POST</code>, etc). This is the desired behavior in most\r
+ cases. However, it is possible to restrict some methods, while\r
+ leaving other methods unrestricted, by enclosing the directives\r
+ in a <directive module="core" type="section">Limit</directive> section.</p>\r
+</summary>\r
+\r
+<seealso><directive module="mod_authz_core">Require</directive></seealso>\r
+<seealso><module>mod_authz_host</module></seealso>\r
+<seealso><module>mod_authz_core</module></seealso>\r
+\r
+<directivesynopsis>\r
+<name>Allow</name>\r
+<description>Controls which hosts can access an area of the\r
+server</description>\r
+<syntax> Allow from all|<var>host</var>|env=<var>env-variable</var>\r
+[<var>host</var>|env=<var>env-variable</var>] ...</syntax>\r
+<contextlist><context>directory</context><context>.htaccess</context>\r
+</contextlist>\r
+<override>Limit</override>\r
+\r
+<usage>\r
+ <p>The <directive>Allow</directive> directive affects which hosts can\r
+ access an area of the server. Access can be controlled by\r
+ hostname, IP Address, IP Address range, or by other\r
+ characteristics of the client request captured in environment\r
+ variables.</p>\r
+\r
+ <p>The first argument to this directive is always\r
+ <code>from</code>. The subsequent arguments can take three\r
+ different forms. If <code>Allow from all</code> is specified, then\r
+ all hosts are allowed access, subject to the configuration of the\r
+ <directive module="mod_access_compat">Deny</directive> and <directive\r
+ module="mod_access_compat">Order</directive> directives as discussed\r
+ below. To allow only particular hosts or groups of hosts to access\r
+ the server, the <em>host</em> can be specified in any of the\r
+ following formats:</p>\r
+\r
+ <dl>\r
+ <dt>A (partial) domain-name</dt>\r
+\r
+ <dd>\r
+ <example><title>Example:</title>\r
+ Allow from apache.org<br />\r
+ Allow from .net example.edu\r
+ </example>\r
+ <p>Hosts whose names match, or end in, this string are allowed\r
+ access. Only complete components are matched, so the above\r
+ example will match <code>foo.apache.org</code> but it will not\r
+ match <code>fooapache.org</code>. This configuration will cause\r
+ Apache to perform a double reverse DNS lookup on the client IP\r
+ address, regardless of the setting of the <directive\r
+ module="core">HostnameLookups</directive> directive. It will do\r
+ a reverse DNS lookup on the IP address to find the associated\r
+ hostname, and then do a forward lookup on the hostname to assure\r
+ that it matches the original IP address. Only if the forward\r
+ and reverse DNS are consistent and the hostname matches will\r
+ access be allowed.</p></dd>\r
+\r
+ <dt>A full IP address</dt>\r
+\r
+ <dd>\r
+ <example><title>Example:</title>\r
+ Allow from 10.1.2.3<br />\r
+ Allow from 192.168.1.104 192.168.1.205\r
+ </example>\r
+ <p>An IP address of a host allowed access</p></dd>\r
+\r
+ <dt>A partial IP address</dt>\r
+\r
+ <dd>\r
+ <example><title>Example:</title>\r
+ Allow from 10.1<br />\r
+ Allow from 10 172.20 192.168.2\r
+ </example>\r
+ <p>The first 1 to 3 bytes of an IP address, for subnet\r
+ restriction.</p></dd>\r
+\r
+ <dt>A network/netmask pair</dt>\r
+\r
+ <dd>\r
+ <example><title>Example:</title>\r
+ Allow from 10.1.0.0/255.255.0.0\r
+ </example>\r
+ <p>A network a.b.c.d, and a netmask w.x.y.z. For more\r
+ fine-grained subnet restriction.</p></dd>\r
+\r
+ <dt>A network/nnn CIDR specification</dt>\r
+\r
+ <dd>\r
+ <example><title>Example:</title>\r
+ Allow from 10.1.0.0/16\r
+ </example>\r
+ <p>Similar to the previous case, except the netmask consists of\r
+ nnn high-order 1 bits.</p></dd>\r
+ </dl>\r
+\r
+ <p>Note that the last three examples above match exactly the\r
+ same set of hosts.</p>\r
+\r
+ <p>IPv6 addresses and IPv6 subnets can be specified as shown\r
+ below:</p>\r
+\r
+ <example>\r
+ Allow from 2001:db8::a00:20ff:fea7:ccea<br />\r
+ Allow from 2001:db8::a00:20ff:fea7:ccea/10\r
+ </example>\r
+\r
+ <p>The third format of the arguments to the\r
+ <directive>Allow</directive> directive allows access to the server\r
+ to be controlled based on the existence of an <a\r
+ href="../env.html">environment variable</a>. When <code>Allow from\r
+ env=<var>env-variable</var></code> is specified, then the request is\r
+ allowed access if the environment variable <var>env-variable</var>\r
+ exists. The server provides the ability to set environment\r
+ variables in a flexible way based on characteristics of the client\r
+ request using the directives provided by\r
+ <module>mod_setenvif</module>. Therefore, this directive can be\r
+ used to allow access based on such factors as the clients\r
+ <code>User-Agent</code> (browser type), <code>Referer</code>, or\r
+ other HTTP request header fields.</p>\r
+\r
+ <example><title>Example:</title>\r
+ SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in<br />\r
+ <Directory /docroot><br />\r
+ <indent>\r
+ Order Deny,Allow<br />\r
+ Deny from all<br />\r
+ Allow from env=let_me_in<br />\r
+ </indent>\r
+ </Directory>\r
+ </example>\r
+\r
+ <p>In this case, browsers with a user-agent string beginning\r
+ with <code>KnockKnock/2.0</code> will be allowed access, and all\r
+ others will be denied.</p>\r
+</usage>\r
+</directivesynopsis>\r
+\r
+<directivesynopsis>\r
+<name>Deny</name>\r
+<description>Controls which hosts are denied access to the\r
+server</description>\r
+<syntax> Deny from all|<var>host</var>|env=<var>env-variable</var>\r
+[<var>host</var>|env=<var>env-variable</var>] ...</syntax>\r
+<contextlist><context>directory</context><context>.htaccess</context>\r
+</contextlist>\r
+<override>Limit</override>\r
+\r
+<usage>\r
+ <p>This directive allows access to the server to be restricted\r
+ based on hostname, IP address, or environment variables. The\r
+ arguments for the <directive>Deny</directive> directive are\r
+ identical to the arguments for the <directive\r
+ module="mod_access_compat">Allow</directive> directive.</p>\r
+</usage>\r
+</directivesynopsis>\r
+\r
+<directivesynopsis>\r
+<name>Order</name>\r
+<description>Controls the default access state and the order in which\r
+<directive>Allow</directive> and <directive>Deny</directive> are\r
+evaluated.</description>\r
+<syntax> Order <var>ordering</var></syntax>\r
+<default>Order Deny,Allow</default>\r
+<contextlist><context>directory</context><context>.htaccess</context>\r
+</contextlist>\r
+<override>Limit</override>\r
+\r
+<usage>\r
+ <p>The <directive>Order</directive> directive controls the default\r
+ access state and the order in which <directive\r
+ module="mod_access_compat">Allow</directive> and <directive\r
+ module="mod_access_compat">Deny</directive> directives are evaluated.\r
+ <var>Ordering</var> is one of</p>\r
+\r
+ <dl>\r
+ <dt><code>Deny,Allow</code></dt>\r
+\r
+ <dd>The <directive module="mod_access_compat">Deny</directive> directives\r
+ are evaluated before the <directive\r
+ module="mod_access_compat">Allow</directive> directives. Access is\r
+ allowed by default. Any client which does not match a\r
+ <directive module="mod_access_compat">Deny</directive> directive or does\r
+ match an <directive module="mod_access_compat">Allow</directive>\r
+ directive will be allowed access to the server.</dd>\r
+\r
+ <dt><code>Allow,Deny</code></dt>\r
+\r
+ <dd>The <directive module="mod_access_compat">Allow</directive>\r
+ directives are evaluated before the <directive\r
+ module="mod_access_compat">Deny</directive> directives. Access is denied\r
+ by default. Any client which does not match an <directive\r
+ module="mod_access_compat">Allow</directive> directive or does match a\r
+ <directive module="mod_access_compat">Deny</directive> directive will be\r
+ denied access to the server.</dd>\r
+\r
+ <dt><code>Mutual-failure</code></dt>\r
+\r
+ <dd>Only those hosts which appear on the <directive\r
+ module="mod_access_compat">Allow</directive> list and do not appear on\r
+ the <directive module="mod_access_compat">Deny</directive> list are\r
+ granted access. This ordering has the same effect as <code>Order\r
+ Allow,Deny</code> and is deprecated in favor of that\r
+ configuration.</dd>\r
+ </dl>\r
+\r
+ <p>Keywords may only be separated by a comma; <em>no whitespace</em> is\r
+ allowed between them. Note that in all cases every <directive\r
+ module="mod_access_compat">Allow</directive> and <directive\r
+ module="mod_access_compat">Deny</directive> statement is evaluated.</p>\r
+\r
+ <p>In the following example, all hosts in the apache.org domain\r
+ are allowed access; all other hosts are denied access.</p>\r
+\r
+ <example>\r
+ Order Deny,Allow<br />\r
+ Deny from all<br />\r
+ Allow from apache.org\r
+ </example>\r
+\r
+ <p>In the next example, all hosts in the apache.org domain are\r
+ allowed access, except for the hosts which are in the\r
+ foo.apache.org subdomain, who are denied access. All hosts not\r
+ in the apache.org domain are denied access because the default\r
+ state is to deny access to the server.</p>\r
+\r
+ <example>\r
+ Order Allow,Deny<br />\r
+ Allow from apache.org<br />\r
+ Deny from foo.apache.org\r
+ </example>\r
+\r
+ <p>On the other hand, if the <directive>Order</directive> in the last\r
+ example is changed to <code>Deny,Allow</code>, all hosts will\r
+ be allowed access. This happens because, regardless of the\r
+ actual ordering of the directives in the configuration file,\r
+ the <code>Allow from apache.org</code> will be evaluated last\r
+ and will override the <code>Deny from foo.apache.org</code>.\r
+ All hosts not in the <code>apache.org</code> domain will also\r
+ be allowed access because the default state will change to\r
+ <em>allow</em>.</p>\r
+\r
+ <p>The presence of an <directive>Order</directive> directive can affect\r
+ access to a part of the server even in the absence of accompanying\r
+ <directive module="mod_access_compat">Allow</directive> and <directive\r
+ module="mod_access_compat">Deny</directive> directives because of its effect\r
+ on the default access state. For example,</p>\r
+\r
+ <example>\r
+ <Directory /www><br />\r
+ <indent>\r
+ Order Allow,Deny<br />\r
+ </indent>\r
+ </Directory>\r
+ </example>\r
+\r
+ <p>will deny all access to the <code>/www</code> directory\r
+ because the default access state will be set to\r
+ <em>deny</em>.</p>\r
+\r
+ <p>The <directive>Order</directive> directive controls the order of access\r
+ directive processing only within each phase of the server's\r
+ configuration processing. This implies, for example, that an\r
+ <directive module="mod_access_compat">Allow</directive> or <directive\r
+ module="mod_access_compat">Deny</directive> directive occurring in a\r
+ <directive module="core" type="section">Location</directive> section will\r
+ always be evaluated after an <directive\r
+ module="mod_access_compat">Allow</directive> or <directive\r
+ module="mod_access_compat">Deny</directive> directive occurring in a\r
+ <directive module="core" type="section">Directory</directive> section or\r
+ <code>.htaccess</code> file, regardless of the setting of the\r
+ <directive>Order</directive> directive. For details on the merging\r
+ of configuration sections, see the documentation on <a\r
+ href="../sections.html">How Directory, Location and Files sections\r
+ work</a>.</p>\r
+</usage>\r
+</directivesynopsis>\r
+\r
+<directivesynopsis>\r
+<name>Satisfy</name>\r
+<description>Interaction between host-level access control and\r
+user authentication</description>\r
+<syntax>Satisfy Any|All</syntax>\r
+<default>Satisfy All</default>\r
+<contextlist><context>directory</context><context>.htaccess</context>\r
+</contextlist>\r
+<override>AuthConfig</override>\r
+<compatibility>Influenced by <directive module="core" type="section"\r
+>Limit</directive> and <directive module="core"\r
+type="section">LimitExcept</directive> in version 2.0.51 and\r
+later</compatibility>\r
+\r
+<usage>\r
+ <p>Access policy if both <directive\r
+ module="mod_authz_host">Allow</directive> and <directive\r
+ module="mod_authz_core">Require</directive> used. The parameter can be\r
+ either <code>All</code> or <code>Any</code>. This directive is only\r
+ useful if access to a particular area is being restricted by both\r
+ username/password <em>and</em> client host address. In this case\r
+ the default behavior (<code>All</code>) is to require that the client\r
+ passes the address access restriction <em>and</em> enters a valid\r
+ username and password. With the <code>Any</code> option the client will be\r
+ granted access if they either pass the host restriction or enter a\r
+ valid username and password. This can be used to password restrict\r
+ an area, but to let clients from particular addresses in without\r
+ prompting for a password.</p>\r
+\r
+ <p>For example, if you wanted to let people on your network have\r
+ unrestricted access to a portion of your website, but require that\r
+ people outside of your network provide a password, you could use a\r
+ configuration similar to the following:</p>\r
+\r
+ <example>\r
+ Require valid-user<br />\r
+ Allow from 192.168.1<br />\r
+ Satisfy Any\r
+ </example>\r
+\r
+ <p>Since version 2.0.51 <directive>Satisfy</directive> directives can\r
+ be restricted to particular methods by <directive module="core"\r
+ type="section">Limit</directive> and <directive module="core" type="section"\r
+ >LimitExcept</directive> sections.</p>\r
+</usage>\r
+ <seealso><directive module="mod_access_compat">Allow</directive></seealso>\r
+ <seealso><directive module="mod_authz_core">Require</directive></seealso>\r
+</directivesynopsis>\r
+\r
+</modulesynopsis>\r
projects / apache / commitdiff