| <?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>Base</status> |
| <sourcefile>mod_access.c</sourcefile> |
| <identifier>access_module</identifier> |
| <compatibility>Available only in versions prior to 2.1</compatibility> |
| |
| <summary> |
| <p>The directives provided by <module>mod_access</module> 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">Allow</directive> and <directive |
| module="mod_access">Deny</directive> directives are used to |
| specify which clients are or are not allowed access to the server, |
| while the <directive module="mod_access">Order</directive> |
| directive sets the default access state, and configures how the |
| <directive module="mod_access">Allow</directive> and <directive |
| module="mod_access">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">Deny</directive> and <directive |
| module="mod_access">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><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.</p></dd> |
| |
| <dt>A full IP address</dt> |
| |
| <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><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><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><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 |
| 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">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">Allow</directive> and <directive |
| module="mod_access">Deny</directive> directives are evaluated. |
| <var>Ordering</var> is one of</p> |
| |
| <dl> |
| <dt><code>Deny,Allow</code></dt> |
| |
| <dd>The <directive module="mod_access">Deny</directive> directives |
| are evaluated before the <directive |
| module="mod_access">Allow</directive> directives. Access is |
| allowed by default. Any client which does not match a |
| <directive module="mod_access">Deny</directive> directive or does |
| match an <directive module="mod_access">Allow</directive> |
| directive will be allowed access to the server.</dd> |
| |
| <dt><code>Allow,Deny</code></dt> |
| |
| <dd>The <directive module="mod_access">Allow</directive> |
| directives are evaluated before the <directive |
| module="mod_access">Deny</directive> directives. Access is denied |
| by default. Any client which does not match an <directive |
| module="mod_access">Allow</directive> directive or does match a |
| <directive module="mod_access">Deny</directive> directive will be |
| denied access to the server.</dd> |
| |
| <dt><code>Mutual-failure</code></dt> |
| |
| <dd>Only those hosts which appear on the <directive |
| module="mod_access">Allow</directive> list and do not appear on |
| the <directive module="mod_access">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; <em>no whitespace</em> is |
| allowed between them. Note that in all cases every <directive |
| module="mod_access">Allow</directive> and <directive |
| module="mod_access">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">Allow</directive> and <directive |
| module="mod_access">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">Allow</directive> or <directive |
| module="mod_access">Deny</directive> directive occurring in a |
| <directive module="core" type="section">Location</directive> section will |
| always be evaluated after an <directive |
| module="mod_access">Allow</directive> or <directive |
| module="mod_access">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> |