From fe39ffb8b90ae4e002ed73fe98617cd590abb467 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 08:33:50 +0200 Subject: Adding upstream version 2.4.56. Signed-off-by: Daniel Baumann --- docs/manual/mod/mod_access_compat.html.en | 499 ++++++++++++++++++++++++++++++ 1 file changed, 499 insertions(+) create mode 100644 docs/manual/mod/mod_access_compat.html.en (limited to 'docs/manual/mod/mod_access_compat.html.en') diff --git a/docs/manual/mod/mod_access_compat.html.en b/docs/manual/mod/mod_access_compat.html.en new file mode 100644 index 0000000..6cea80a --- /dev/null +++ b/docs/manual/mod/mod_access_compat.html.en @@ -0,0 +1,499 @@ + + + + + +mod_access_compat - Apache HTTP Server Version 2.4 + + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+ +
+

Apache Module mod_access_compat

+
+

Available Languages:  en  | + fr  | + ja 

+
+ + + + +
Description:Group authorizations based on host (name or IP +address)
Status:Extension
Module Identifier:access_compat_module
Source File:mod_access_compat.c
Compatibility:Available in Apache HTTP Server 2.3 as a compatibility module with +previous versions of Apache httpd 2.x. The directives provided by this module +have been deprecated by the new authz refactoring. Please see +mod_authz_host
+

Summary

+ +

The directives provided by mod_access_compat are + used in <Directory>, + <Files>, and + <Location> sections + as well as .htaccess + 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 environment variables. The Allow and Deny directives are used to + specify which clients are or are not allowed access to the server, + while the Order + directive sets the default access state, and configures how the + Allow and Deny directives interact with each + other.

+ +

Both host-based access restrictions and password-based + authentication may be implemented simultaneously. In that case, + the Satisfy directive is used + to determine how the two sets of restrictions interact.

+ +

Note

+

The directives provided by mod_access_compat have + been deprecated by mod_authz_host. + Mixing old directives like Order, Allow or Deny with new ones like + Require is technically possible + but discouraged. This module was created to support + configurations containing only old directives to facilitate the 2.4 upgrade. + Please check the upgrading guide for more + information. +

+
+ +

In general, access restriction directives apply to all + access methods (GET, PUT, + POST, 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 <Limit> section.

+ +

Merging of configuration sections

+

When any directive provided by this module is used in a new + configuration section, no directives provided by this module are + inherited from previous configuration sections.

+
+ +
+ + +
top
+

Allow Directive

+ + + + + + + +
Description:Controls which hosts can access an area of the +server
Syntax: Allow from all|host|env=[!]env-variable +[host|env=[!]env-variable] ...
Context:directory, .htaccess
Override:Limit
Status:Extension
Module:mod_access_compat
+

The Allow 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.

+ +

The first argument to this directive is always + from. The subsequent arguments can take three + different forms. If Allow from all is specified, then + all hosts are allowed access, subject to the configuration of the + Deny and Order directives as discussed + below. To allow only particular hosts or groups of hosts to access + the server, the host can be specified in any of the + following formats:

+ +
+
A (partial) domain-name
+ +
+ 
Allow from example.org
+Allow from .net example.edu
+ +

Hosts whose names match, or end in, this string are allowed + access. Only complete components are matched, so the above + example will match foo.example.org but it will not + match fooexample.org. This configuration will cause + Apache httpd to perform a double DNS lookup on the client IP + address, regardless of the setting of the HostnameLookups 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.

+ +
A full IP address
+ +
+ 
Allow from 10.1.2.3
+Allow from 192.168.1.104 192.168.1.205
+ +

An IP address of a host allowed access

+ +
A partial IP address
+ +
+ 
Allow from 10.1
+Allow from 10 172.20 192.168.2
+ +

The first 1 to 3 bytes of an IP address, for subnet + restriction.

+ +
A network/netmask pair
+ +
+ 
Allow from 10.1.0.0/255.255.0.0
+ +

A network a.b.c.d, and a netmask w.x.y.z. For more + fine-grained subnet restriction.

+ +
A network/nnn CIDR specification
+ +
+ 
Allow from 10.1.0.0/16
+ +

Similar to the previous case, except the netmask consists of + nnn high-order 1 bits.

+
+ +

Note that the last three examples above match exactly the + same set of hosts.

+ +

IPv6 addresses and IPv6 subnets can be specified as shown + below:

+ + 
Allow from 2001:db8::a00:20ff:fea7:ccea
+Allow from 2001:db8::a00:20ff:fea7:ccea/10
+ + +

The third format of the arguments to the + Allow directive allows access to the server + to be controlled based on the existence of an environment variable. When Allow from + env=env-variable is specified, then the request is + allowed access if the environment variable env-variable + exists. When Allow from env=!env-variable is + specified, then the request is allowed access if the environment + variable env-variable doesn't exist. + 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 + mod_setenvif. Therefore, this directive can be + used to allow access based on such factors as the clients + User-Agent (browser type), Referer, or + other HTTP request header fields.

+ + 
SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
+<Directory "/docroot">
+    Order Deny,Allow
+    Deny from all
+    Allow from env=let_me_in
+</Directory>
+ + +

In this case, browsers with a user-agent string beginning + with KnockKnock/2.0 will be allowed access, and all + others will be denied.

+ +

Merging of configuration sections

+

When any directive provided by this module is used in a new + configuration section, no directives provided by this module are + inherited from previous configuration sections.

+
+ + +
+
top
+

Deny Directive

+ + + + + + + +
Description:Controls which hosts are denied access to the +server
Syntax: Deny from all|host|env=[!]env-variable +[host|env=[!]env-variable] ...
Context:directory, .htaccess
Override:Limit
Status:Extension
Module:mod_access_compat
+

This directive allows access to the server to be restricted + based on hostname, IP address, or environment variables. The + arguments for the Deny directive are + identical to the arguments for the Allow directive.

+ +
+
top
+

Order Directive

+ + + + + + + + +
Description:Controls the default access state and the order in which +Allow and Deny are +evaluated.
Syntax: Order ordering
Default:Order Deny,Allow
Context:directory, .htaccess
Override:Limit
Status:Extension
Module:mod_access_compat
+ +

The Order directive, along with the + Allow and + Deny directives, + controls a three-pass access control system. The first pass + processes either all Allow or all Deny directives, as specified + by the Order + directive. The second pass parses the rest of the directives + (Deny or + Allow). The third + pass applies to all requests which do not match either of the first + two.

+ +

Note that all Allow and Deny directives are + processed, unlike a typical firewall, where only the first match is + used. The last match is effective (also unlike a typical firewall). + Additionally, the order in which lines appear in the configuration + files is not significant -- all Allow lines are processed as + one group, all Deny lines are considered as + another, and the default state is considered by itself.

+ +

Ordering is one of:

+ +
+
Allow,Deny
+ +
First, all Allow directives are + evaluated; at least one must match, or the request is rejected. + Next, all Deny + directives are evaluated. If any matches, the request is rejected. + Last, any requests which do not match an Allow or a Deny directive are denied + by default.
+ +
Deny,Allow
+ +
First, all Deny directives are + evaluated; if any match, the request is denied + unless it also matches an Allow directive. Any + requests which do not match any Allow or Deny directives are + permitted.
+ +
Mutual-failure
+ +
This order has the same effect as Order + Allow,Deny and is deprecated in its favor.
+
+ +

Keywords may only be separated by a comma; no whitespace + is allowed between them.

+ + + + + + + + + + + + + + + + + + + + + + + +
MatchAllow,Deny resultDeny,Allow result
Match Allow onlyRequest allowedRequest allowed
Match Deny onlyRequest deniedRequest denied
No matchDefault to second directive: DeniedDefault to second directive: Allowed
Match both Allow & DenyFinal match controls: DeniedFinal match controls: Allowed
+ +

In the following example, all hosts in the example.org domain + are allowed access; all other hosts are denied access.

+ + 
Order Deny,Allow
+Deny from all
+Allow from example.org
+ + +

In the next example, all hosts in the example.org domain are + allowed access, except for the hosts which are in the + foo.example.org subdomain, who are denied access. All hosts not + in the example.org domain are denied access because the default + state is to Deny + access to the server.

+ + 
Order Allow,Deny
+Allow from example.org
+Deny from foo.example.org
+ + +

On the other hand, if the Order in the + last example is changed to Deny,Allow, all hosts will + be allowed access. This happens because, regardless of the actual + ordering of the directives in the configuration file, the + Allow from example.org will be evaluated last and will + override the Deny from foo.example.org. All hosts not in + the example.org domain will also be allowed access + because the default state is Allow.

+ +

The presence of an Order directive can + affect access to a part of the server even in the absence of + accompanying Allow + and Deny + directives because of its effect on the default access state. For + example,

+ + 
<Directory "/www">
+    Order Allow,Deny
+</Directory>
+ + +

will Deny all access to the /www directory + because the default access state is set to + Deny.

+ +

The Order directive controls the order of access + directive processing only within each phase of the server's + configuration processing. This implies, for example, that an + Allow or Deny directive occurring in a + <Location> section will + always be evaluated after an Allow or Deny directive occurring in a + <Directory> section or + .htaccess file, regardless of the setting of the + Order directive. For details on the merging + of configuration sections, see the documentation on How Directory, Location and Files sections + work.

+ +

Merging of configuration sections

+

When any directive provided by this module is used in a new + configuration section, no directives provided by this module are + inherited from previous configuration sections.

+
+ + +
+
top
+

Satisfy Directive

+ + + + + + + + + +
Description:Interaction between host-level access control and +user authentication
Syntax:Satisfy Any|All
Default:Satisfy All
Context:directory, .htaccess
Override:AuthConfig
Status:Extension
Module:mod_access_compat
Compatibility:Influenced by <Limit> and <LimitExcept> in version 2.0.51 and +later
+

Access policy if both Allow and Require used. The parameter can be + either All or Any. This directive is only + useful if access to a particular area is being restricted by both + username/password and client host address. In this case + the default behavior (All) is to require that the client + passes the address access restriction and enters a valid + username and password. With the Any option the client will be + granted access if they either pass the host restriction or enter a + valid username and password. This can be used to password restrict + an area, but to let clients from particular addresses in without + prompting for a password.

+ +

For example, if you wanted to let people on your network have + unrestricted access to a portion of your website, but require that + people outside of your network provide a password, you could use a + configuration similar to the following:

+ + 
Require valid-user
+Allow from 192.168.1
+Satisfy Any
+ + +

+ Another frequent use of the Satisfy directive + is to relax access restrictions for a subdirectory: +

+ + 
<Directory "/var/www/private">
+    Require valid-user
+</Directory>
+
+<Directory "/var/www/private/public">
+    Allow from all
+    Satisfy Any
+</Directory>
+ + +

In the above example, authentication will be required for the + /var/www/private directory, but will not be required + for the /var/www/private/public directory.

+ +

Since version 2.0.51 Satisfy directives can + be restricted to particular methods by <Limit> and <LimitExcept> sections.

+ +

Merging of configuration sections

+

When any directive provided by this module is used in a new + configuration section, no directives provided by this module are + inherited from previous configuration sections.

+
+ + +

See also

+ +
+
+
+

Available Languages:  en  | + fr  | + ja 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file -- cgit v1.2.3