diff options
| author | Bradley Nicholes <bnicholes@apache.org> | 2006-01-11 14:30:28 +0000 |
|---|---|---|
| committer | Bradley Nicholes <bnicholes@apache.org> | 2006-01-11 14:30:28 +0000 |
| commit | 9fed4c73d7d572fa468b407c44a1923e520f98ae (patch) | |
| tree | f0742c9a64ec0809f85318194f4aa74f6e5110fe /docs | |
| parent | bb2af228cdf3372ce92a7764928b641751c32b61 (diff) | |
| download | httpd-9fed4c73d7d572fa468b407c44a1923e520f98ae.tar.gz | |
Authz refactoring
Merge from branches/authz-dev
Basically here is a list of what has been done:
- Convert all of the authz modules from hook based to provider based
- Remove the ap_requires field from the core_dir_config structure
- Remove the function ap_requires() since its functionality is no
longer supported or necessary in the refactoring
- Remove the calls to ap_some_auth_required() in the core request
handling to allow the hooks to be called in all cases.
- Add the new module mod_authz_core which will act as the authorization
provider vector and contain common authz directives such as 'Require',
'Reject' and '<RequireAlias>'
- Add the new module mod_authn_core which will contain common
authentication directives such as 'AuthType', 'AuthName' and
'<AuthnProviderAlias>'
- Move the check for METHOD_MASK out of the authz providers and into
the authz_core provider vector
- Define the status codes that can be returned by the authz providers
as AUTHZ_DENIED, AUTHZ_GRANTED and AUTHZ_GENERAL_ERROR
- Remove the 'Satisfy' directive
- Implement the '<RequireAll>', '<RequireOne>' block directives to
handle the 'and' and 'or' logic for authorization.
- Remove the 'AuthzXXXAuthoritative' directives from all of the authz
providers
- Implement the 'Reject' directive that will deny authorization if the
argument is true
- Fold the 'Reject' directive into the '<RequireAll>', '<RequireOne>'
logic
- Reimplement the host based authorization functionality provided by
'allow', 'deny' and 'order' as authz providers
- Remove the 'allow', 'deny' and 'order' directives
- Merge mod_authn_alias into mod_authn_core
- Add '<RequireAlias>' functionality which is similar to
'<AuthnProviderAlias>' but specific to authorization aliasing
- Remove all of the references to the 'authzxxxAuthoritative'
directives from the documentation
- Remove the 'Satisfy' directive from the documentation
- Remove 'Allow', 'Deny', 'Order' directives from the documentation
- Document '<RequireAll>', '<RequireOne>', 'Reject' directives
- Reimplement the APIs ap_auth_type(), ap_auth_name() as optional
functions and move the actual implementation into mod_authn_core
- Reimplement the API ap_some_auth_required() as an optional function
and move the actual implementation into mod_authz_core
Major Changes:
- Added the directives <RequireAll>, <RequireOne>, <RequireAlias>,
Reject
- Expanded the functionality of the directive 'Require' to handle all
authorization and access control
- Added the new authz providers 'env', 'ip', 'host', 'all' to handle
host-based access control
- Removed the directives 'Allow', 'Deny', 'Order', 'Satisfy',
'AuthzXXXAuthoritative'
- Removed the ap_require() API
- Moved the directives 'AuthType', 'AuthName' out of mod_core and into
mod_authn_core
- Moved the directive 'Require' out of mod_core and into
mod_authz_core
- Merged mod_authn_alias into mod_authn_core
- Renamed mod_authz_dbm authz providers from 'group' and 'file-group'
to 'dbm-group' and 'dbm-file-group'
Benefits:
- All authorization and access control is now handle through two
directives, 'Require' and 'Reject'
- Authorization has been expanded to allow for complex 'AND/OR' control
logic through the directives '<RequireAll>' and '<RequireOne>'
- Configuration is now much simpler and consistent across the board
- Other modules like mod_ssl and mod_proxy should be able to plug into
and take advantage of the same provider based authorization mechanism
by implementing their own providers
Issues:
- Backwards compatibility between 2.2 and 2.3 configurations will be
broken in the area of authorization and access control due to the fact
that the directives 'allow', 'deny', 'order' and 'satisfy' have been
removed. When moving from 2.2 to 2.3 these directives will have to be
changed to 'Require all granted', 'Require all denied' or some variation
of the authz host-based providers.
- Existing third party authorization modules will have to adapt to the
new structure.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@368027 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'docs')
24 files changed, 496 insertions, 744 deletions
diff --git a/docs/conf/extra/httpd-autoindex.conf.in b/docs/conf/extra/httpd-autoindex.conf.in index 13b400d1ad..91ddb534c5 100644 --- a/docs/conf/extra/httpd-autoindex.conf.in +++ b/docs/conf/extra/httpd-autoindex.conf.in @@ -22,8 +22,7 @@ Alias /icons/ "@exp_iconsdir@/" <Directory "@exp_iconsdir@"> Options Indexes MultiViews AllowOverride None - Order allow,deny - Allow from all + Require all granted </Directory> # diff --git a/docs/conf/extra/httpd-dav.conf.in b/docs/conf/extra/httpd-dav.conf.in index 56a1a819ab..ec8a5e59b6 100644 --- a/docs/conf/extra/httpd-dav.conf.in +++ b/docs/conf/extra/httpd-dav.conf.in @@ -24,6 +24,7 @@ Alias /uploads "@@ServerRoot@@/uploads" # You can use the htdigest program to create the password database: # htdigest -c "@@ServerRoot@@/user.passwd" DAV-upload admin AuthUserFile "@@ServerRoot@@/user.passwd" + AuthDigestProvider file # Allow universal read-access, but writes are restricted # to the admin user. diff --git a/docs/conf/extra/httpd-info.conf.in b/docs/conf/extra/httpd-info.conf.in index db316c032e..261f096d7e 100644 --- a/docs/conf/extra/httpd-info.conf.in +++ b/docs/conf/extra/httpd-info.conf.in @@ -12,9 +12,7 @@ <Location /server-status> SetHandler server-status - Order deny,allow - Deny from all - Allow from .example.com + Require host .example.com </Location> # @@ -31,7 +29,5 @@ # <Location /server-info> SetHandler server-info - Order deny,allow - Deny from all - Allow from .example.com + Require host .example.com </Location> diff --git a/docs/conf/extra/httpd-manual.conf.in b/docs/conf/extra/httpd-manual.conf.in index 874b0933ec..fc9e616944 100644 --- a/docs/conf/extra/httpd-manual.conf.in +++ b/docs/conf/extra/httpd-manual.conf.in @@ -12,8 +12,7 @@ AliasMatch ^/manual(?:/(?:de|en|es|fr|ja|ko|pt-br|ru))?(/.*)?$ "@exp_manualdir@$ <Directory "@exp_manualdir@"> Options Indexes AllowOverride None - Order allow,deny - Allow from all + Require all granted <Files *.html> SetHandler type-map diff --git a/docs/conf/extra/httpd-multilang-errordoc.conf.in b/docs/conf/extra/httpd-multilang-errordoc.conf.in index d3192508b5..617f5f607f 100644 --- a/docs/conf/extra/httpd-multilang-errordoc.conf.in +++ b/docs/conf/extra/httpd-multilang-errordoc.conf.in @@ -26,8 +26,7 @@ Alias /error/ "@exp_errordir@/" Options IncludesNoExec AddOutputFilter Includes html AddHandler type-map var - Order allow,deny - Allow from all + Require all granted LanguagePriority en cs de es fr it ja ko nl pl pt-br ro sv tr ForceLanguagePriority Prefer Fallback </Directory> diff --git a/docs/conf/extra/httpd-userdir.conf.in b/docs/conf/extra/httpd-userdir.conf.in index f424dd437d..210fba0a71 100644 --- a/docs/conf/extra/httpd-userdir.conf.in +++ b/docs/conf/extra/httpd-userdir.conf.in @@ -17,12 +17,10 @@ UserDir public_html AllowOverride FileInfo AuthConfig Limit Indexes Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec <Limit GET POST OPTIONS> - Order allow,deny - Allow from all + Require all granted </Limit> <LimitExcept GET POST OPTIONS> - Order deny,allow - Deny from all + Require all denied </LimitExcept> </Directory> diff --git a/docs/conf/httpd.conf.in b/docs/conf/httpd.conf.in index e493562a15..a165e57512 100644 --- a/docs/conf/httpd.conf.in +++ b/docs/conf/httpd.conf.in @@ -112,8 +112,7 @@ DocumentRoot "@exp_htdocsdir@" <Directory /> Options FollowSymLinks AllowOverride None - Order deny,allow - Deny from all + Require all denied </Directory> # @@ -151,8 +150,7 @@ DocumentRoot "@exp_htdocsdir@" # # Controls who can get stuff from this server. # - Order allow,deny - Allow from all + Require all granted </Directory> @@ -169,9 +167,7 @@ DocumentRoot "@exp_htdocsdir@" # viewed by Web clients. # <FilesMatch "^\.ht"> - Order allow,deny - Deny from all - Satisfy All + Require all denied </FilesMatch> # @@ -265,8 +261,7 @@ LogLevel warn <Directory "@exp_cgidir@"> AllowOverride None Options None - Order allow,deny - Allow from all + Require all granted </Directory> # diff --git a/docs/manual/developer/request.xml b/docs/manual/developer/request.xml index 72d5cf68b0..7bb7689274 100644 --- a/docs/manual/developer/request.xml +++ b/docs/manual/developer/request.xml @@ -149,56 +149,18 @@ <p>Needs Documentation. Code is:</p> <example><pre> -switch (ap_satisfies(r)) { -case SATISFY_ALL: -case SATISFY_NOSPEC: - if ((access_status = ap_run_access_checker(r)) != 0) { - return decl_die(access_status, "check access", r); - } - - if (ap_some_auth_required(r)) { - if (((access_status = ap_run_check_user_id(r)) != 0) - || !ap_auth_type(r)) { - return decl_die(access_status, ap_auth_type(r) - ? "check user. No user file?" - : "perform authentication. AuthType not set!", - r); - } - - if (((access_status = ap_run_auth_checker(r)) != 0) - || !ap_auth_type(r)) { - return decl_die(access_status, ap_auth_type(r) - ? "check access. No groups file?" - : "perform authentication. AuthType not set!", - r); - } - } - break; - -case SATISFY_ANY: - if (((access_status = ap_run_access_checker(r)) != 0)) { - if (!ap_some_auth_required(r)) { + if ((access_status = ap_run_access_checker(r)) != 0) { return decl_die(access_status, "check access", r); } - if (((access_status = ap_run_check_user_id(r)) != 0) - || !ap_auth_type(r)) { - return decl_die(access_status, ap_auth_type(r) - ? "check user. No user file?" - : "perform authentication. AuthType not set!", - r); + if ((access_status = ap_run_check_user_id(r)) != 0) { + return decl_die(access_status, "check user", r); } - if (((access_status = ap_run_auth_checker(r)) != 0) - || !ap_auth_type(r)) { - return decl_die(access_status, ap_auth_type(r) - ? "check access. No groups file?" - : "perform authentication. AuthType not set!", - r); + if ((access_status = ap_run_auth_checker(r)) != 0) { + return decl_die(access_status, "check authorization", r); } - } - break; -}</pre> + </pre> </example> </section> diff --git a/docs/manual/mod/allmodules.xml b/docs/manual/mod/allmodules.xml index 0bac66e23c..d76e4b8507 100644 --- a/docs/manual/mod/allmodules.xml +++ b/docs/manual/mod/allmodules.xml @@ -9,11 +9,13 @@ <modulefile>mod_auth_digest.xml</modulefile> <modulefile>mod_authn_alias.xml</modulefile> <modulefile>mod_authn_anon.xml</modulefile> + <modulefile>mod_authn_core.xml</modulefile> <modulefile>mod_authn_dbd.xml</modulefile> <modulefile>mod_authn_dbm.xml</modulefile> <modulefile>mod_authn_default.xml</modulefile> <modulefile>mod_authn_file.xml</modulefile> <modulefile>mod_authnz_ldap.xml</modulefile> + <modulefile>mod_authz_core.xml</modulefile> <modulefile>mod_authz_dbd.xml</modulefile> <modulefile>mod_authz_dbm.xml</modulefile> <modulefile>mod_authz_default.xml</modulefile> diff --git a/docs/manual/mod/core.xml b/docs/manual/mod/core.xml index 3d9447e70f..d5402df6c4 100644 --- a/docs/manual/mod/core.xml +++ b/docs/manual/mod/core.xml @@ -470,69 +470,6 @@ be passed through</description> </directivesynopsis> <directivesynopsis> -<name>AuthName</name> -<description>Authorization realm for use in HTTP -authentication</description> -<syntax>AuthName <var>auth-domain</var></syntax> -<contextlist><context>directory</context><context>.htaccess</context> -</contextlist> -<override>AuthConfig</override> - -<usage> - <p>This directive sets the name of the authorization realm for a - directory. This realm is given to the client so that the user - knows which username and password to send. - <directive>AuthName</directive> takes a single argument; if the - realm name contains spaces, it must be enclosed in quotation - marks. It must be accompanied by <directive - module="core">AuthType</directive> and <directive - module="core">Require</directive> directives, and directives such - as <directive module="mod_authn_file">AuthUserFile</directive> and - <directive module="mod_authz_groupfile">AuthGroupFile</directive> to - work.</p> - - <p>For example:</p> - - <example> - AuthName "Top Secret" - </example> - - <p>The string provided for the <code>AuthName</code> is what will - appear in the password dialog provided by most browsers.</p> -</usage> -<seealso><a - href="../howto/auth.html">Authentication, Authorization, and - Access Control</a></seealso> -</directivesynopsis> - -<directivesynopsis> -<name>AuthType</name> -<description>Type of user authentication</description> -<syntax>AuthType Basic|Digest</syntax> -<contextlist><context>directory</context><context>.htaccess</context> -</contextlist> -<override>AuthConfig</override> - -<usage> - <p>This directive selects the type of user authentication for a - directory. The authentication types available are - <code>Basic</code> (implemented by - <module>mod_auth_basic</module>) and <code>Digest</code> - (implemented by <module>mod_auth_digest</module>).</p> - - <p>To implement authentication, you must also use the <directive - module="core">AuthName</directive> and <directive - module="core">Require</directive> directives. In addition, the - server must have an authentication-provider module such as - <module>mod_authn_file</module> and an authorization module such - as <module>mod_authz_user</module>.</p> -</usage> - -<seealso><a href="../howto/auth.html">Authentication, Authorization, - and Access Control</a></seealso> -</directivesynopsis> - -<directivesynopsis> <name>CGIMapExtension</name> <description>Technique for locating the interpreter for CGI scripts</description> @@ -2392,101 +2329,6 @@ directory</description> </directivesynopsis> <directivesynopsis> -<name>Require</name> -<description>Selects which authenticated users can access -a resource</description> -<syntax>Require <var>entity-name</var> [<var>entity-name</var>] ...</syntax> -<contextlist><context>directory</context><context>.htaccess</context> -</contextlist> -<override>AuthConfig</override> - -<usage> - <p>This directive selects which authenticated users can access a - resource. The restrictions are processed by authorization - modules. Some of the allowed syntaxes provided by - <module>mod_authz_user</module> and - <module>mod_authz_groupfile</module> are:</p> - - <dl> - <dt><code>Require user <var>userid</var> [<var>userid</var>] - ...</code></dt> - <dd>Only the named users can access the resource.</dd> - - <dt><code>Require group <var>group-name</var> [<var>group-name</var>] - ...</code></dt> - <dd>Only users in the named groups can access the resource.</dd> - - <dt><code>Require valid-user</code></dt> - <dd>All valid users can access the resource.</dd> - </dl> - - <p>Other authorization modules that implement require options - include <module>mod_authnz_ldap</module>, - <module>mod_authz_dbm</module>, and - <module>mod_authz_owner</module>.</p> - - <p><directive>Require</directive> must be accompanied by - <directive module="core">AuthName</directive> and <directive - module="core">AuthType</directive> directives, and directives such - as <directive module="mod_authn_file">AuthUserFile</directive> - and <directive module="mod_authz_groupfile">AuthGroupFile</directive> (to - define users and groups) in order to work correctly. Example:</p> - - <example> - AuthType Basic<br /> - AuthName "Restricted Resource"<br /> - AuthUserFile /web/users<br /> - AuthGroupFile /web/groups<br /> - Require group admin - </example> - - <p>Access controls which are applied in this way are effective for - <strong>all</strong> methods. <strong>This is what is normally - desired.</strong> If you wish to apply access controls only to - specific methods, while leaving other methods unprotected, then - place the <directive>Require</directive> statement into a - <directive module="core" type="section">Limit</directive> - section.</p> - - <p>If <directive>Require</directive> is used together with - the <directive module="mod_authz_host">Allow</directive> or - <directive module="mod_authz_host">Deny</directive> directives, - then the interaction of these restrictions is controlled by - the <directive module="core">Satisfy</directive> directive.</p> - - <note><title>Removing controls in subdirectories</title> - <p>The following example shows how to use the <directive - module="core">Satisfy</directive> directive to disable access - controls in a subdirectory of a protected directory. This - technique should be used with caution, because it will also - disable any access controls imposed by - <module>mod_authz_host</module>.</p> - <example> - <Directory /path/to/protected/><br /> - <indent> - Require user david<br /> - </indent> - </Directory><br /> - <Directory /path/to/protected/unprotected><br /> - <indent> - # All access controls and authentication are disabled<br /> - # in this directory<br /> - Satisfy Any<br /> - Allow from all<br /> - </indent> - </Directory><br /> - </example> - </note> - -</usage> - -<seealso><a href="../howto/auth.html">Authentication, Authorization, - and Access Control</a></seealso> -<seealso><directive module="core">Satisfy</directive></seealso> -<seealso><module>mod_authz_host</module></seealso> -</directivesynopsis> - -<directivesynopsis> <name>RLimitCPU</name> <description>Limits the CPU consumption of processes launched by Apache children</description> @@ -2594,55 +2436,6 @@ processes launched by Apache children</description> </directivesynopsis> <directivesynopsis> -<name>Satisfy</name> -<description>Interaction between host-level access control and -user authentication</description> -<syntax>Satisfy Any|All</syntax> -<default>Satisfy All</default> -<contextlist><context>directory</context><context>.htaccess</context> -</contextlist> -<override>AuthConfig</override> -<compatibility>Influenced by <directive module="core" type="section" ->Limit</directive> and <directive module="core" -type="section">LimitExcept</directive> in version 2.0.51 and -later</compatibility> - -<usage> - <p>Access policy if both <directive - module="mod_authz_host">Allow</directive> and <directive - module="core">Require</directive> used. The parameter can be - either <code>All</code> or <code>Any</code>. This directive is only - useful if access to a particular area is being restricted by both - username/password <em>and</em> client host address. In this case - the default behavior (<code>All</code>) is to require that the client - passes the address access restriction <em>and</em> enters a valid - username and password. With the <code>Any</code> 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.</p> - - <p>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:</p> - - <example> - Require valid-user<br /> - Allow from 192.168.1<br /> - Satisfy Any - </example> - - <p>Since version 2.0.51 <directive>Satisfy</directive> directives can - be restricted to particular methods by <directive module="core" - type="section">Limit</directive> and <directive module="core" type="section" - >LimitExcept</directive> sections.</p> -</usage> - <seealso><directive module="mod_authz_host">Allow</directive></seealso> - <seealso><directive module="core">Require</directive></seealso> -</directivesynopsis> - -<directivesynopsis> <name>ScriptInterpreterSource</name> <description>Technique for locating the interpreter for CGI scripts</description> diff --git a/docs/manual/mod/mod_auth_digest.xml b/docs/manual/mod/mod_auth_digest.xml index 283a4196fb..cf65d1a4e7 100644 --- a/docs/manual/mod/mod_auth_digest.xml +++ b/docs/manual/mod/mod_auth_digest.xml @@ -38,7 +38,6 @@ <seealso><directive module="core">AuthName</directive></seealso> <seealso><directive module="core">AuthType</directive></seealso> <seealso><directive module="core">Require</directive></seealso> -<seealso><directive module="core">Satisfy</directive></seealso> <seealso><a href="../howto/auth.html">Authentication howto</a></seealso> <section id="using"><title>Using Digest Authentication</title> diff --git a/docs/manual/mod/mod_authn_alias.xml b/docs/manual/mod/mod_authn_alias.xml index 6ba51d0c1b..9bf23c09ca 100644 --- a/docs/manual/mod/mod_authn_alias.xml +++ b/docs/manual/mod/mod_authn_alias.xml @@ -76,7 +76,6 @@ AuthType Basic<br /> AuthName LDAP_Protected_Place<br /> - AuthzLDAPAuthoritative off<br /> require valid-user<br /> </indent> </Directory><br /> diff --git a/docs/manual/mod/mod_authn_core.xml b/docs/manual/mod/mod_authn_core.xml new file mode 100644 index 0000000000..4fcf0b243d --- /dev/null +++ b/docs/manual/mod/mod_authn_core.xml @@ -0,0 +1,103 @@ +<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<!-- $LastChangedRevision: 151408 $ -->
+
+<!--
+ Copyright 2002-2005 The Apache Software Foundation or its licensors, as
+ applicable.
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_authn_core.xml.meta">
+
+<name>mod_authn_core</name>
+<description>Core Authentication</description>
+<status>Base</status>
+<sourcefile>mod_authn_core.c</sourcefile>
+<identifier>authn_core_module</identifier>
+<compatibility>Available in Apache 2.3 and later</compatibility>
+
+<summary>
+ <p>This module provides core authentication capabilities to
+ allow or deny access to portions of the web site.
+ <module>mod_authn_core</module> provides directives that are
+ common to all authentication providers.</p>
+</summary>
+
+<directivesynopsis>
+<name>AuthName</name>
+<description>Authorization realm for use in HTTP
+authentication</description>
+<syntax>AuthName <var>auth-domain</var></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>This directive sets the name of the authorization realm for a
+ directory. This realm is given to the client so that the user
+ knows which username and password to send.
+ <directive>AuthName</directive> takes a single argument; if the
+ realm name contains spaces, it must be enclosed in quotation
+ marks. It must be accompanied by <directive
+ module="mod_authn_core">AuthType</directive> and <directive
+ module="mod_authz_core">Require</directive> directives, and directives such
+ as <directive module="mod_authn_file">AuthUserFile</directive> and
+ <directive module="mod_authz_groupfile">AuthGroupFile</directive> to
+ work.</p>
+
+ <p>For example:</p>
+
+ <example>
+ AuthName "Top Secret"
+ </example>
+
+ <p>The string provided for the <code>AuthName</code> is what will
+ appear in the password dialog provided by most browsers.</p>
+</usage>
+<seealso><a
+ href="../howto/auth.html">Authentication, Authorization, and
+ Access Control</a></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthType</name>
+<description>Type of user authentication</description>
+<syntax>AuthType Basic|Digest</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>This directive selects the type of user authentication for a
+ directory. The authentication types available are
+ <code>Basic</code> (implemented by
+ <module>mod_auth_basic</module>) and <code>Digest</code>
+ (implemented by <module>mod_auth_digest</module>).</p>
+
+ <p>To implement authentication, you must also use the <directive
+ module="mod_authn_core">AuthName</directive> and <directive
+ module="mod_authz_core">Require</directive> directives. In addition, the
+ server must have an authentication-provider module such as
+ <module>mod_authn_file</module> and an authorization module such
+ as <module>mod_authz_user</module>.</p>
+</usage>
+
+<seealso><a href="../howto/auth.html">Authentication, Authorization,
+ and Access Control</a></seealso>
+</directivesynopsis>
+
+
+</modulesynopsis>
diff --git a/docs/manual/mod/mod_authn_core.xml.meta b/docs/manual/mod/mod_authn_core.xml.meta new file mode 100644 index 0000000000..5161d87507 --- /dev/null +++ b/docs/manual/mod/mod_authn_core.xml.meta @@ -0,0 +1,11 @@ +<?xml version="1.0" encoding="UTF-8" ?>
+
+<metafile>
+ <basename>mod_authn_core</basename>
+ <path>/mod/</path>
+ <relpath>..</relpath>
+
+ <variants>
+ <variant>en</variant>
+ </variants>
+</metafile>
diff --git a/docs/manual/mod/mod_authnz_ldap.xml b/docs/manual/mod/mod_authnz_ldap.xml index 526de29f98..f9f25dd4bf 100644 --- a/docs/manual/mod/mod_authnz_ldap.xml +++ b/docs/manual/mod/mod_authnz_ldap.xml @@ -301,9 +301,7 @@ for HTTP Basic authentication.</description> <p>If this directive exists, <module>mod_authnz_ldap</module> grants access to any user that has successfully authenticated during the search/bind phase. Requires that <module>mod_authz_user</module> be - loaded and that the - <directive module="mod_authnz_ldap">AuthzLDAPAuthoritative</directive> - directive be set to off.</p> + loaded.</p> </section> <section id="requser"><title>require ldap-user</title> @@ -573,17 +571,10 @@ require valid-user that gets created in the web</p> <example><pre> AuthLDAPURL "the url" -AuthzLDAPAuthoritative off AuthGroupFile <em>mygroupfile</em> require group <em>mygroupfile</em> </pre></example> - <p><directive module="mod_authnz_ldap">AuthzLDAPAuthoritative</directive> - must be off to allow <module>mod_authnz_ldap</module> to decline group - authentication so that Apache will fall back to file - authentication for checking group membership. This allows the - FrontPage-managed group file to be used.</p> - <section id="howitworks"><title>How It Works</title> <p>FrontPage restricts access to a web by adding the <code>require @@ -644,25 +635,6 @@ require group <em>mygroupfile</em> </section> <directivesynopsis> -<name>AuthzLDAPAuthoritative</name> -<description>Prevent other authentication modules from -authenticating the user if this one fails</description> -<syntax>AuthzLDAPAuthoritative on|off</syntax> -<default>AuthzLDAPAuthoritative on</default> -<contextlist><context>directory</context><context>.htaccess</context> -</contextlist> -<override>AuthConfig</override> - -<usage> - <p>Set to <code>off</code> if this module should let other - authentication modules attempt to authenticate the user, should - authentication with this module fail. Control is only passed on - to lower modules if there is no DN or rule that matches the - supplied user name (as passed by the client).</p> -</usage> -</directivesynopsis> - -<directivesynopsis> <name>AuthLDAPBindDN</name> <description>Optional DN to use in binding to the LDAP server</description> <syntax>AuthLDAPBindDN <em>distinguished-name</em></syntax> diff --git a/docs/manual/mod/mod_authz_core.xml b/docs/manual/mod/mod_authz_core.xml new file mode 100644 index 0000000000..9faac243ee --- /dev/null +++ b/docs/manual/mod/mod_authz_core.xml @@ -0,0 +1,222 @@ +<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<!-- $LastChangedRevision: 151408 $ -->
+
+<!--
+ Copyright 2002-2005 The Apache Software Foundation or its licensors, as
+ applicable.
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_authz_core.xml.meta">
+
+<name>mod_authz_core</name>
+<description>Core Authorization</description>
+<status>Base</status>
+<sourcefile>mod_authz_core.c</sourcefile>
+<identifier>authz_core_module</identifier>
+<compatibility>Available in Apache 2.3 and later</compatibility>
+
+<summary>
+ <p>This module provides core authorization capabilities so that
+ authenticated users can be allowed or denied access to portions
+ of the web site. <module>mod_authz_core</module> provides the
+ functionality to register various authorization providers. It is
+ usually used in conjunction with an authentication
+ provider module such as <module>mod_authn_file</module> and an
+ authorization module such as <module>mod_authz_user</module>. It
+ also allows for "AND" and "OR" logic to be applied to the
+ authorization processing.</p>
+</summary>
+
+<directivesynopsis>
+<name>Require</name>
+<description>Selects which authenticated users can access
+a resource</description>
+<syntax>Require <var>entity-name</var> [<var>entity-name</var>] ...</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>This directive selects which authenticated users can access a
+ resource. The restrictions are processed by authorization
+ modules. Some of the allowed syntaxes provided by
+ <module>mod_authz_user</module> and
+ <module>mod_authz_groupfile</module> are:</p>
+
+ <dl>
+ <dt><code>Require user <var>userid</var> [<var>userid</var>]
+ ...</code></dt>
+ <dd>Only the named users can access the resource.</dd>
+
+ <dt><code>Require group <var>group-name</var> [<var>group-name</var>]
+ ...</code></dt>
+ <dd>Only users in the named groups can access the resource.</dd>
+
+ <dt><code>Require valid-user</code></dt>
+ <dd>All valid users can access the resource.</dd>
+ </dl>
+
+ <p>Other authorization modules that implement require options
+ include <module>mod_authnz_ldap</module>,
+ <module>mod_authz_dbm</module>, <module>mod_authz_dbd</module>,
+ <module>mod_authz_host</module>, and
+ <module>mod_authz_owner</module>.</p>
+
+ <p>For a complete authentication and authorization configuration,
+ <directive>Require</directive> must be accompanied by
+ <directive module="mod_authn_core">AuthName</directive>, <directive
+ module="mod_authn_core">AuthType</directive> and
+ <directive module="mod_auth_basic">AuthBasicProvider</directive>
+ directives, and directives such as
+ <directive module="mod_authn_file">AuthUserFile</directive>
+ and <directive module="mod_authz_groupfile">AuthGroupFile</directive> (to
+ define users and groups) in order to work correctly. Example:</p>
+
+ <example>
+ AuthType Basic<br />
+ AuthName "Restricted Resource"<br />
+ AuthBasicProvider file<br />
+ AuthUserFile /web/users<br />
+ AuthGroupFile /web/groups<br />
+ Require group admin
+ </example>
+
+ <p>Access controls which are applied in this way are effective for
+ <strong>all</strong> methods. <strong>This is what is normally
+ desired.</strong> If you wish to apply access controls only to
+ specific methods, while leaving other methods unprotected, then
+ place the <directive>Require</directive> statement into a
+ <directive module="core" type="section">Limit</directive>
+ section.</p>
+
+</usage>
+
+<seealso><a href="../howto/auth.html">Authentication, Authorization,
+ and Access Control</a></seealso>
+<seealso><module>mod_authz_host</module></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>Reject</name>
+<description>Rejects which authenticated users can access
+a resource</description>
+<syntax>Reject <var>entity-name</var> [<var>entity-name</var>] ...</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>This directive is similar to the
+ <directive module="mod_authz_core">Require</directive> directive however
+ it rejects which authenticated users can access a resource. The
+ restrictions are processed by authorization modules. See the
+ <directive module="mod_authz_core">Require</directive> directive for details
+ about usage.</p>
+</usage>
+
+<seealso><a href="../howto/auth.html">Authentication, Authorization,
+ and Access Control</a></seealso>
+<seealso><module>mod_authz_host</module></seealso>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>SatisfyAll</name>
+<description>Enclose a group of authorization directives that must all
+be satisfied in order to grant access to a resource. This block allows
+for 'AND' logic to be applied to various authorization providers.</description>
+<syntax><SatisfyAll>
+... </SatisfyAll></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p><directive type="section">SatisfyAll</directive> and
+ <code></SatisfyAll></code> are used to enclose a group of
+ authorization directives that must all be satisfied in order to
+ grant access to a resource.</p>
+
+ <p>The <directive module="mod_authz_core">
+ <SatisfyAll></directive> block as well as the
+ <directive module="mod_authz_core"><SatisfyOne></directive> block
+ allow you to apply "AND" and "OR" logic to the authorization processing.
+ For example the following authorization block would apply the logic:</p>
+
+ <p><var>
+ if ((user == "John") || <br />
+ ((Group == "admin") && (ldap-group <ldap-object> contains auth'ed_user) &&<br />
+ ((ldap-attribute dept == "sales") ||
+ (file-group contains contains auth'ed_user))))<br />
+ then<br />
+ auth_granted<br />
+ else<br />
+ auth_denied<br />
+ </var></p>
+
+ <example>
+ <Directory /www/mydocs><br />
+ Authname ...<br />
+ AuthBasicProvider ...<br />
+ ...<br />
+ Require user John<br />
+ <SatisfyAll><br />
+ Require Group admins<br />
+ Require ldap-group cn=mygroup,o=foo<br />
+ <SatisfyOne><br />
+ Require ldap-attribute dept="sales"<br />
+ Require file-group<br />
+ </SatisfyOne><br />
+ </SatisfyAll><br />
+ </Directory><br />
+ </example>
+
+</usage>
+
+<seealso><a href="../howto/auth.html">Authentication, Authorization,
+ and Access Control</a></seealso>
+
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>SatisfyOne</name>
+<description>Enclose a group of authorization directives that must
+satisfy at least one in order to grant access to a resource. This
+block allows for 'OR' logic to be applied to various authorization
+providers.</description>
+<syntax><SatisfyOne>
+... </SatisfyOne></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p><directive type="section">SatisfyOne</directive> and
+ <code></SatisfyOne></code> are used to enclose a group of
+ authorization directives that must satisfy at least one in order to
+ grant access to a resource.</p>
+
+ <p>See the <directive module="mod_authz_core">
+ <SatisfyAll></directive> directive for a usage example.</p>
+
+</usage>
+
+<seealso><a href="../howto/auth.html">Authentication, Authorization,
+ and Access Control</a></seealso>
+
+</directivesynopsis>
+
+</modulesynopsis>
diff --git a/docs/manual/mod/mod_authz_core.xml.meta b/docs/manual/mod/mod_authz_core.xml.meta new file mode 100644 index 0000000000..b2bef72f58 --- /dev/null +++ b/docs/manual/mod/mod_authz_core.xml.meta @@ -0,0 +1,11 @@ +<?xml version="1.0" encoding="UTF-8" ?>
+
+<metafile>
+ <basename>mod_authz_core</basename>
+ <path>/mod/</path>
+ <relpath>..</relpath>
+
+ <variants>
+ <variant>en</variant>
+ </variants>
+</metafile>
diff --git a/docs/manual/mod/mod_authz_dbd.xml b/docs/manual/mod/mod_authz_dbd.xml index 6002c86aee..03cf4ba910 100644 --- a/docs/manual/mod/mod_authz_dbd.xml +++ b/docs/manual/mod/mod_authz_dbd.xml @@ -38,7 +38,6 @@ </summary> <seealso><directive module="core">Require</directive></seealso> -<seealso><directive module="core">Satisfy</directive></seealso> <seealso><directive module="mod_dbd">DBDriver</directive></seealso> <seealso><directive module="mod_dbd">DBDParams</directive></seealso> @@ -182,40 +181,4 @@ header is present</description> </usage> </directivesynopsis> -<directivesynopsis> -<name>AuthzDBDAuthoritative</name> -<description>Sets whether authorization will be passed on to lower level -modules</description> -<syntax>AuthzDBDAuthoritative On|Off</syntax> -<default>AuthzDBDAuthoritative On</default> -<contextlist><context>directory</context></contextlist> - -<usage> - <p>Setting the <directive>AuthzDBDAuthoritative</directive> - directive explicitly to <code>Off</code> allows group authorization - to be handled by another authz module if the userID is not - in any authorized dbd-group. 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> - 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>AuthAuthoritative</directive> setting.</p> - - <p>A common use for this is in conjunction with one of the - auth providers; such or - <module>mod_authn_file</module>. Whereas this DBD 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 group - will result in an Authentication Required reply. Not - setting it thus keeps the system secure and forces an NCSA - compliant behaviour.</p> -</usage> -</directivesynopsis> - </modulesynopsis> diff --git a/docs/manual/mod/mod_authz_dbm.xml b/docs/manual/mod/mod_authz_dbm.xml index 6d6ca04ff3..f53029c623 100644 --- a/docs/manual/mod/mod_authz_dbm.xml +++ b/docs/manual/mod/mod_authz_dbm.xml @@ -37,7 +37,6 @@ </summary> <seealso><directive module="core">Require</directive></seealso> -<seealso><directive module="core">Satisfy</directive></seealso> <directivesynopsis> <name>AuthDBMGroupFile</name> @@ -119,51 +118,4 @@ store list of user groups</description> </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> -</contextlist> -<override>AuthConfig</override> - -<usage> - <p>Setting the <directive>AuthzDBMAuthoritative</directive> - 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> - 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>AuthAuthoritative</directive> setting.</p> - - <p>A common use for this is in conjunction with one of the - 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 group - will result in an Authentication Required reply. Not - setting it thus keeps the system secure and forces an NCSA - compliant behaviour.</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> - </modulesynopsis> diff --git a/docs/manual/mod/mod_authz_groupfile.xml b/docs/manual/mod/mod_authz_groupfile.xml index d3aed88d66..b590113a62 100644 --- a/docs/manual/mod/mod_authz_groupfile.xml +++ b/docs/manual/mod/mod_authz_groupfile.xml @@ -37,7 +37,6 @@ </summary> <seealso><directive module="core">Require</directive></seealso> -<seealso><directive module="core">Satisfy</directive></seealso> <directivesynopsis> <name>AuthGroupFile</name> @@ -75,36 +74,4 @@ of user groups for authorization</description> </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> -</contextlist> -<override>AuthConfig</override> - -<usage> - <p>Setting the <directive>AuthzGroupFileAuthoritative</directive> - 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 group - will result in an Authentication Required reply. Not - setting it thus keeps the system secure and forces an NCSA - compliant behaviour.</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> - </modulesynopsis> diff --git a/docs/manual/mod/mod_authz_host.xml b/docs/manual/mod/mod_authz_host.xml index 915aaecc6a..89f332bfbc 100644 --- a/docs/manual/mod/mod_authz_host.xml +++ b/docs/manual/mod/mod_authz_host.xml @@ -28,31 +28,21 @@ address)</description> <status>Base</status> <sourcefile>mod_authz_host.c</sourcefile> <identifier>authz_host_module</identifier> -<compatibility>Available in Apache 2.1 and later</compatibility> +<compatibility>Available in Apache 2.3 and later</compatibility> <summary> - <p>The directives provided by <module>mod_authz_host</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 + <p>The authorization providers implemented by <module>mod_authz_host</module> are + registered using the <directive module="mod_authz_core">Require</directive> or + <directive module="mod_authz_core">Reject</directive> directives. These + directives can be referenced within a + <directive module="core" type="section">Directory</directive>, + <directive module="core" type="section">Files</directive>, + or <directive module="core" type="section">Location</directive> section 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_authz_host">Allow</directive> and <directive - module="mod_authz_host">Deny</directive> directives are used to - specify which clients are or are not allowed access to the server, - while the <directive module="mod_authz_host">Order</directive> - directive sets the default access state, and configures how the - <directive module="mod_authz_host">Allow</directive> and <directive - module="mod_authz_host">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> + href="../env.html">environment variables</a>.</p> <p>In general, access restriction directives apply to all access methods (<code>GET</code>, <code>PUT</code>, @@ -62,111 +52,33 @@ address)</description> 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 +<seealso><a href="../howto/auth.html">Authentication, Authorization, + and Access Control</a></seealso> +<seealso><directive module="mod_authz_core">Require</directive></seealso> +<seealso><directive module="mod_authz_core">Reject</directive></seealso> + +<section id="requiredirectives"><title>The require Directives</title> + + <p>Apache's <directive module="mod_authz_core">Require</directive> and + <directive module="mod_authz_core">Reject</directive> directives are + 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>env</code>, <code>ip</code>, + <code>host</code> and <code>all</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, 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_authz_host">Deny</directive> and <directive - module="mod_authz_host">Order</directive> directives as discussed - below. To allow only particular hosts or groups of hosts to access - the server, the <em>host</em> 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<br /> - Allow from .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.apache.org</code> but it will not - match <code>fooapache.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></dd> - - <dt>A full IP address</dt> - - <dd> - <example><title>Example:</title> - Allow from 10.1.2.3<br /> - Allow from 192.168.1.104 192.168.1.205 - </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<br /> - Allow from 10 172.20 192.168.2 - </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> +<section id="reqenv"><title>require env</title> - <p>IPv6 addresses and IPv6 subnets can be specified as shown - below:</p> - - <example> - Allow from 2001:db8::a00:20ff:fea7:ccea<br /> - Allow from 2001:db8::a00:20ff:fea7:ccea/10 - </example> - - <p>The third format of the arguments to the - <directive>Allow</directive> directive allows access to the server + <p>The <code>env</code> provider 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 + href="../env.html">environment variable</a>. When <code>Require + 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 @@ -175,162 +87,126 @@ server</description> 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 /> + Require 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_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 <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. - <var>Ordering</var> is one of</p> - - <dl> - <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 - <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><code>Allow,Deny</code></dt> - - <dd>The <directive module="mod_authz_host">Allow</directive> - directives are evaluated before the <directive - module="mod_authz_host">Deny</directive> directives. Access is denied - by default. Any client which does not match an <directive - module="mod_authz_host">Allow</directive> directive or does match a - <directive module="mod_authz_host">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_authz_host">Allow</directive> list and do not appear on - the <directive module="mod_authz_host">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_authz_host">Allow</directive> and <directive - module="mod_authz_host">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> +</section> + +<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> - Order Deny,Allow<br /> - Deny from all<br /> - Allow from apache.org + Require ip 10.1.2.3<br /> + Require ip 192.168.1.104 192.168.1.205 </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> + <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> - Order Allow,Deny<br /> - Allow from apache.org<br /> - Deny from foo.apache.org + Require host apache.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.apache.org</code> but it will not + match <code>fooapache.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="reqall"><title>require all</title> + + <p>The <code>all</code> provider mimics the functionality the + was previously provided by the 'Allow from all' and 'Deny from all' + directives. This provider can take one of two arguments which are + 'granted' or 'denied'. The following examples will grant or deny + access to all requests.</p> - <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 - <em>allow</em>.</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_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> + <example> + Require all granted<br /> + </example> <example> - <Directory /www><br /> - <indent> - Order Allow,Deny<br /> - </indent> - </Directory> + Require all denied<br /> </example> - <p>will deny all access to the <code>/www</code> directory - because the default access state will be set to - <em>deny</em>.</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_authz_host">Allow</directive> or <directive - module="mod_authz_host">Deny</directive> directive occurring in a - <directive module="core" type="section">Location</directive> section will - always be evaluated after an <directive - module="mod_authz_host">Allow</directive> or <directive - module="mod_authz_host">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> +</section> + + +</section> + </modulesynopsis> diff --git a/docs/manual/mod/mod_authz_owner.xml b/docs/manual/mod/mod_authz_owner.xml index 66e68954fe..bff20aff22 100644 --- a/docs/manual/mod/mod_authz_owner.xml +++ b/docs/manual/mod/mod_authz_owner.xml @@ -70,7 +70,6 @@ </note> </summary> <seealso><directive module="core">Require</directive></seealso> -<seealso><directive module="core">Satisfy</directive></seealso> <section id="examples"><title>Configuration Examples</title> @@ -93,7 +92,6 @@ AuthName MyPrivateFiles<br /> AuthBasicProvider dbm<br /> AuthDBMUserFile /usr/local/apache2/etc/.htdbm-all<br /> - Satisfy All<br /> Require file-owner<br /> </indent> </Directory> @@ -132,39 +130,4 @@ </section> </section> -<directivesynopsis> -<name>AuthzOwnerAuthoritative</name> -<description>Sets whether authorization will be passed on to lower level -modules</description> -<syntax>AuthzOwnerAuthoritative On|Off</syntax> -<default>AuthzOwnerAuthoritative On</default> -<contextlist><context>directory</context><context>.htaccess</context> -</contextlist> -<override>AuthConfig</override> - -<usage> - <p>Setting the <directive>AuthzOwnerAuthoritative</directive> - directive explicitly to <code>Off</code> allows for - user authorization to be passed on to lower level modules (as defined - in the <code>modules.c</code> files) if:</p> - - <ul> - <li>in the case of <code>file-owner</code> the file-system owner does not - match the supplied web-username or could not be determined, or</li> - - <li>in the case of <code>file-group</code> the file-system group does not - contain the supplied web-username or could not be determined.</li> - </ul> - - <p>Note that setting the value to <code>Off</code> also allows the - combination of <code>file-owner</code> and <code>file-group</code>, so - access will be allowed if either one or the other (or both) match.</p> - - <p>By default, control is not passed on and an authorization failure - will result in an "Authentication Required" reply. Not - setting it to <code>Off</code> thus keeps the system secure and forces - an NCSA compliant behaviour.</p> -</usage> -</directivesynopsis> - </modulesynopsis> diff --git a/docs/manual/mod/mod_authz_user.xml b/docs/manual/mod/mod_authz_user.xml index c9d006971b..35703b6f8b 100644 --- a/docs/manual/mod/mod_authz_user.xml +++ b/docs/manual/mod/mod_authz_user.xml @@ -38,30 +38,5 @@ grant access to all successfully authenticated users.</p> </summary> <seealso><directive module="core">Require</directive></seealso> -<seealso><directive module="core">Satisfy</directive></seealso> - -<directivesynopsis> -<name>AuthzUserAuthoritative</name> -<description>Sets whether authorization will be passed on to lower level -modules</description> -<syntax>AuthzUserAuthoritative On|Off</syntax> -<default>AuthzUserAuthoritative On</default> -<contextlist><context>directory</context><context>.htaccess</context> -</contextlist> -<override>AuthConfig</override> - -<usage> - <p>Setting the <directive>AuthzUserAuthoritative</directive> - directive explicitly to <code>Off</code> allows for - user authorization to be passed on to lower level modules (as defined - in the <code>modules.c</code> files) if there is <strong>no - user</strong> matching the supplied userID.</p> - - <p>By default, control is not passed on and an unknown user - will result in an Authentication Required reply. Not - setting it to <code>Off</code> thus keeps the system secure and forces - an NCSA compliant behaviour.</p> -</usage> -</directivesynopsis> </modulesynopsis> diff --git a/docs/manual/mod/mod_ldap.xml b/docs/manual/mod/mod_ldap.xml index a432341de1..b22cadb228 100644 --- a/docs/manual/mod/mod_ldap.xml +++ b/docs/manual/mod/mod_ldap.xml @@ -81,7 +81,6 @@ by other LDAP modules</description> Allow from yourdomain.example.com<br /> AuthLDAPEnabled on<br /> AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one<br /> - AuthLDAPAuthoritative on<br /> require valid-user<br /> </indent> </Location> @@ -212,7 +211,6 @@ by other LDAP modules</description> Allow from yourdomain.example.com<br /> AuthLDAPEnabled on<br /> AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one<br /> - AuthLDAPAuthoritative on<br /> require valid-user<br /> </indent> </Location> @@ -234,7 +232,6 @@ by other LDAP modules</description> AuthLDAPEnabled on<br /> LDAPTrustedMode TLS AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one<br /> - AuthLDAPAuthoritative on<br /> require valid-user<br /> </indent> </Location> @@ -287,7 +284,6 @@ by other LDAP modules</description> AuthLDAPEnabled on<br /> LDAPTrustedClientCert CERT_NICKNAME <nickname> [password]<br /> AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one<br /> - AuthLDAPAuthoritative on<br /> require valid-user<br /> </indent> </Location> @@ -355,7 +351,6 @@ by other LDAP modules</description> LDAPTrustedClientCert CERT_BASE64 /certs/cert1.pem<br /> LDAPTrustedClientCert KEY_BASE64 /certs/key1.pem<br /> AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one<br /> - AuthLDAPAuthoritative on<br /> require valid-user<br /> </indent> </Location> |