Apache模块mod_authz_core

AuthMerging 指令

启用授权后，除非指定了不同的授权指令集，否则通常每个后续配置节都将继承它。这是默认操作，与的显式设置相对应AuthMerging Off。

但是，在某些情况下，希望合并配置节时将配置节的授权与其前身的授权相结合。两个选项可用于这种情况下，And 和Or。

当配置节包含AuthMerging And 或时AuthMerging Or，其授权逻辑将与最接近的前任的授权逻辑（根据配置节的整体顺序）组合在一起，后者也包含授权逻辑，就好像两个节分别联合包含在 <RequireAll>或 <RequireAny> 指令中。

<Directory "/www/docs">
    AuthType Basic
    AuthName Documents
    AuthBasicProvider file
    AuthUserFile "/usr/local/apache/passwd/passwords"
    Require group alpha
</Directory>

<Directory "/www/docs/ab">
    AuthMerging Or
    Require group beta
</Directory>

<Directory "/www/docs/ab/gamma">
    Require group gamma
</Directory>

<AuthzProviderAlias> 指令

<AuthzProviderAlias>和 </AuthzProviderAlias>用来封装一组授权指令，可以使用该指令由别名引用Require。

如果在Require-Parameters中需要几个参数，则必须将它们用引号引起来。否则，仅考虑第一个。

# In this example, for both addresses to be taken into account, they MUST be enclosed
# between quotation marks
<AuthzProviderAlias ip reject-ips "XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY">
</AuthzProviderAlias>

<Directory "/path/to/dir">
    <RequireAll>
        Require not reject-ips
        Require all granted
    </RequireAll>
</Directory>

AuthzSendForbiddenOnFailure 指令

如果身份验证成功但授权失败，则默认情况下，Apache HTTPD将使用HTTP响应代码“ 401 UNAUTHORIZED”进行响应。通常，这会导致浏览器再次向用户显示密码对话，这在所有情况下都是不希望的。 AuthzSendForbiddenOnFailure允许将响应代码更改为“ 403 FORBIDDEN”。

需要 指令

该指令测试是否根据特定的授权提供者和指定的限制对已认证的用户进行了授权。mod_authz_core提供以下通用授权提供者：

Require all granted

无条件允许访问。

Require all denied

无条件拒绝访问。

Require env env-var [env-var] ...

仅在设置了给定环境变量之一的情况下才允许访问。

Require method http-method [http-method] ...

仅允许使用给定的HTTP方法进行访问。

Require expr expression

如果expression的计算结果为true，则允许访问。

一些允许的语法提供的mod_authz_user， mod_authz_host和mod_authz_groupfile有：

Require user userid [userid] ...

只有指定的用户可以访问资源。

Require group group-name [group-name] ...

只有命名组中的用户才能访问资源。

Require valid-user

所有有效用户都可以访问资源。

Require ip 10 172.20 192.168.2

指定IP地址范围内的客户端可以访问资源。

实现需要选择其他授权模块包括mod_authnz_ldap， mod_authz_dbm，mod_authz_dbd， mod_authz_owner和mod_ssl。

在大多数情况下，一个完整的认证和授权的配置，Require必须附有 AuthName，AuthType和 AuthBasicProvider或 AuthDigestProvider 指令以及诸如 AuthUserFile 和AuthGroupFile为了正确地（以定义用户和组）工作。例：

AuthType Basic
AuthName "Restricted Resource"
AuthBasicProvider file
AuthUserFile "/web/users"
AuthGroupFile "/web/groups"
Require group admin

以这种方式应用的访问控制对所有方法均有效 。这是通常所希望的。如果您希望仅将访问控制应用于特定方法，而其他方法不受保护，则将该Require语句放在一 <Limit> 节中。

Require指令的结果可以通过使用not选项来否定 。与其他否定授权指令一样<RequireNone>，否定指令Require只能失败或返回中立的结果，因此可能永远不会独立授权请求。

在以下示例中，alpha 和beta组中的所有用户都得到了授权，但同时也在该reject组中的用户除外。

<Directory "/www/docs">
    <RequireAll>
        Require group alpha beta
        Require not group reject
    </RequireAll>
</Directory>

如果Require在单个配置节中使用了多个指令 ，并且没有将它们包含在另一个授权指令（如）中 <RequireAll>，则它们隐式包含在 <RequireAny> 指令中。因此，第一个授权用户的用户会授权整个请求，随后的Require指令将被忽略。

也可以看看

• 访问控制方法
• 授权容器
• mod_authn_core
• mod_authz_host

<RequireAll> 指令

<RequireAll>并且 </RequireAll>用于封装一组授权指令，这些授权指令中的任何一个都必须失败，并且至少有一个必须成功才能使该<RequireAll>指令成功。

如果指令中包含的所有<RequireAll>指令均未 失败，并且至少有一个成功，则该 <RequireAll>指令成功。如果没有成功也没有失败，则返回中立结果。在所有其他情况下，它都会失败。

也可以看看

• 授权容器
• 身份验证，授权和访问控制

<RequireAny> 指令

<RequireAny>并且 </RequireAny>用于封装一组授权指令，为了使该<RequireAny>指令成功，必须授权一组授权指令。

如果指令中包含的一个或多个 <RequireAny>指令成功，则该<RequireAny>指令成功。如果没有成功也没有失败，则返回中立结果。在所有其他情况下，它都会失败。

也可以看看

• 授权容器
• 身份验证，授权和访问控制

<RequireNone> 指令

<RequireNone>并且 </RequireNone>用于封装一组授权伪指令，为了使该<RequireNone>伪指令不会失败，这些授权伪指令必须不成功 。

如果指令中包含的一个或多个 <RequireNone>指令成功，则该<RequireNone>指令失败。在所有其他情况下，它返回中性结果。因此，与其他否定授权指令一样Require not，它永远无法独立地授权请求，因为它永远不会返回成功的结果。但是，可以使用它来限制有权访问资源的用户集。

也可以看看

• 授权容器
• 身份验证，授权和访问控制