cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov<?xml version="1.0"?>

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov<!DOCTYPE modulesynopsis SYSTEM "/style/modulesynopsis.dtd">

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov<?xml-stylesheet type="text/xsl" href="/style/manual.en.xsl"?>

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov

d8899526551cbfe112e0ecc8280003a8349fc531Nikolai Kondrashov

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov<modulesynopsis metafile="mod_authz_host.xml.meta">

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov<name>mod_authz_host</name>

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov<description>Group authorizations based on host (name or IP

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashovaddress)</description>

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov<status>Base</status>

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov<sourcefile>mod_authz_host.c</sourcefile>

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov<identifier>authz_host_module</identifier>

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov<compatibility>Available in Apache 2.3 and later</compatibility>

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov<summary>

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov <p>The authorization providers implemented by <module>mod_authz_host</module> are

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov registered using the <directive module="mod_authz_core">Require</directive>

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov directive. The directive can be referenced within a

cbff3fcdce5b0377a62fbe74f32e476efbf7ca9cNikolai Kondrashov <directive module="core" type="section">Directory</directive>,

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik <directive module="core" type="section">Files</directive>,

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik or <directive module="core" type="section">Location</directive> section

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik as well as <code><a href="core.html#accessfilename">.htaccess</a>

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik </code> files to control access to particular parts of the server.

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik Access can be controlled based on the client hostname or IP address.</p>

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik <p>In general, access restriction directives apply to all

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik access methods (<code>GET</code>, <code>PUT</code>,

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik <code>POST</code>, etc). This is the desired behavior in most

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik cases. However, it is possible to restrict some methods, while

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik leaving other methods unrestricted, by enclosing the directives

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik in a <directive module="core" type="section">Limit</directive> section.</p>

900778b5afd0143005cfd40cc67ad5086481f7eeLukas Slebodnik</summary>

<seealso><a href="/howto/auth.html">Authentication, Authorization,

and Access Control</a></seealso>

<seealso><directive module="mod_authz_core">Require</directive></seealso>

<section id="requiredirectives"><title>The Require Directives</title>

<p>Apache's <directive module="mod_authz_core">Require</directive>

directive is used during the authorization phase to ensure that a user is allowed or

denied access to a resource. mod_authz_host extends the

authorization types with <code>ip</code> and <code>host</code>.

Other authorization types may also be

used but may require that additional authorization modules be loaded.</p>

<p>These authorization providers affect which hosts can

access an area of the server. Access can be controlled by

hostname, IP Address, or IP Address range.</p>

<section id="reqip"><title>Require ip</title>

<p>The <code>ip</code> provider allows access to the server

to be controlled based on the IP address of the remote client.

When <code>Require ip <var>ip-address</var></code> is specified,

then the request is allowed access if the IP address matches.</p>

<p>A full IP address:</p>

<example>

Require ip 10.1.2.3<br />

Require ip 192.168.1.104 192.168.1.205

</example>

<p>An IP address of a host allowed access</p>

<p>A partial IP address:</p>

<example>

Require ip 10.1<br />

Require ip 10 172.20 192.168.2

</example>

<p>The first 1 to 3 bytes of an IP address, for subnet

restriction.</p>

<p>A network/netmask pair:</p>

<example>

Require ip 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>

<p>A network/nnn CIDR specification:</p>

<example>

Require ip 10.1.0.0/16

</example>

<p>Similar to the previous case, except the netmask consists of

nnn high-order 1 bits.</p>

<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>

Require ip 2001:db8::a00:20ff:fea7:ccea<br />

Require ip 2001:db8::a00:20ff:fea7:ccea/10

</example>

</section>

<section id="reqhost"><title>Require host</title>

<p>The <code>host</code> provider allows access to the server

to be controlled based on the host name of the remote client.

When <code>Require host <var>host-name</var></code> is specified,

then the request is allowed access if the host name matches.</p>

<p>A (partial) domain-name</p>

<example>

Require host example.org<br />

Require host .net example.edu

</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.example.org</code> but it will not

match <code>fooexample.org</code>. This configuration will cause

Apache to perform a double reverse DNS lookup on the client IP

address, regardless of the setting of the <directive

module="core">HostnameLookups</directive> directive. It will do

a reverse DNS lookup on the IP address to find the associated

hostname, and then do a forward lookup on the hostname to assure

that it matches the original IP address. Only if the forward

and reverse DNS are consistent and the hostname matches will

access be allowed.</p>

</section>

<section id="reqlocal"><title>Require local</title>

<p>The <code>local</code> provider allows access to the server if any

of the following conditions is true:</p>

<ul>

<li>the client address matches 127.0.0.0/8</li>

<li>the client address is ::1</li>

<li>both the client and the server address of the connection are

the same</li>

</ul>

<p>This allows a convenient way to match connections that originate from

the local host:</p>

<example>

Require local

</example>

</section>

</section>

</modulesynopsis>