granicus.if.org Git - apache/blob - docs/manual/mod/mod_authz_core.xml

   1 <?xml version="1.0"?>
   2 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
   3 <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
   4 <!-- $LastChangedRevision$ -->
   5
   6 <!--
   7  Licensed to the Apache Software Foundation (ASF) under one or more
   8  contributor license agreements.  See the NOTICE file distributed with
   9  this work for additional information regarding copyright ownership.
  10  The ASF licenses this file to You under the Apache License, Version 2.0
  11  (the "License"); you may not use this file except in compliance with
  12  the License.  You may obtain a copy of the License at
  13
  14      http://www.apache.org/licenses/LICENSE-2.0
  15
  16  Unless required by applicable law or agreed to in writing, software
  17  distributed under the License is distributed on an "AS IS" BASIS,
  18  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  19  See the License for the specific language governing permissions and
  20  limitations under the License.
  21 -->
  22
  23 <modulesynopsis metafile="mod_authz_core.xml.meta">
  24
  25 <name>mod_authz_core</name>
  26 <description>Core Authorization</description>
  27 <status>Base</status>
  28 <sourcefile>mod_authz_core.c</sourcefile>
  29 <identifier>authz_core_module</identifier>
  30 <compatibility>Available in Apache HTTPD 2.3 and later</compatibility>
  31
  32 <summary>
  33     <p>This module provides core authorization capabilities so that
  34     authenticated users can be allowed or denied access to portions
  35     of the web site. <module>mod_authz_core</module> provides the
  36     functionality to register various authorization providers. It is
  37     usually used in conjunction with an authentication
  38     provider module such as <module>mod_authn_file</module> and an
  39     authorization module such as <module>mod_authz_user</module>. It
  40     also allows for advanced logic to be applied to the
  41     authorization processing.</p>
  42 </summary>
  43
  44 <section id="authzalias"><title>Creating Authorization Provider Aliases</title>
  45
  46     <p>Extended authorization providers can be created within the configuration
  47     file and assigned an alias name.  The alias providers can then be referenced
  48     through the <directive module="mod_authz_core">Require</directive> directive
  49     in the same way as a base authorization provider.  Besides the ability to
  50     create and alias an extended provider, it also allows the same extended
  51     authorization provider to be reference by multiple locations.
  52     </p>
  53
  54     <section id="example"><title>Example</title>
  55         <p>The example below creates two different ldap authorization provider
  56         aliases based on the ldap-group authorization provider.  This example
  57         allows a single authorization location to check group membership within
  58         multiple ldap hosts:
  59         </p>
  60
  61         <example><title>Example</title>
  62           &lt;AuthzProviderAlias ldap-group ldap-group-alias1 cn=my-group,o=ctx&gt;<br />
  63           <indent>
  64              AuthLDAPBindDN cn=youruser,o=ctx<br />
  65              AuthLDAPBindPassword yourpassword<br />
  66              AuthLDAPURL ldap://ldap.host/o=ctx<br />
  67           </indent>
  68           &lt;/AuthzProviderAlias&gt;<br /><br />
  69           &lt;AuthzProviderAlias ldap-group ldap-group-alias2
  70            cn=my-other-group,o=dev&gt;<br />
  71           <indent>
  72              AuthLDAPBindDN cn=yourotheruser,o=dev<br />
  73              AuthLDAPBindPassword yourotherpassword<br />
  74              AuthLDAPURL ldap://other.ldap.host/o=dev?cn<br />
  75           </indent>
  76           &lt;/AuthzProviderAlias&gt;<br /><br />
  77
  78           Alias /secure /webpages/secure<br />
  79           &lt;Directory /webpages/secure&gt;<br />
  80           <indent>
  81              Require all granted<br /><br />
  82
  83              AuthBasicProvider file<br /><br />
  84
  85              AuthType Basic<br />
  86              AuthName LDAP_Protected_Place<br /><br />
  87
  88              #implied OR operation<br />
  89              Require ldap-group-alias1<br />
  90              Require ldap-group-alias2<br />
  91           </indent> &lt;/Directory&gt;<br />
  92         </example>
  93     </section>
  94
  95 </section>
  96
  97 <section id="logic"><title>Authorization Containers</title>
  98
  99     <p>The authorization container directives
 100     <directive module="mod_authz_core" type="section">RequireAll</directive>,
 101     <directive module="mod_authz_core" type="section">RequireAny</directive>
 102     and
 103     <directive module="mod_authz_core" type="section">RequireNone</directive>
 104     may be combined with each other and with the
 105     <directive module="mod_authz_core">Require</directive>
 106     directive to express complex authorization logic.</p>
 107
 108     <p>The example below expresses the following authorization logic.
 109     In order to access the resource, the user must either be the
 110     <code>superadmin</code> user, or belong to both the
 111     <code>admins</code> group and the <code>Administrators</code> LDAP
 112     group and either belong to the <code>sales</code> group or
 113     have the LDAP <code>dept</code> attribute <code>sales</code>.
 114     Furthermore, in order to access the resource, the user must
 115     not belong to either the <code>temps</code> group or the
 116     LDAP group <code>Temporary Employees</code>.</p>
 117
 118     <example>
 119         &lt;Directory /www/mydocs&gt;
 120         <indent>
 121             &lt;RequireAll&gt;
 122             <indent>
 123                 &lt;RequireAny&gt;
 124                 <indent>
 125                     Require user superadmin<br />
 126                     &lt;RequireAll&gt;
 127                     <indent>
 128                         Require group admins<br />
 129                         Require ldap-group cn=Administrators,o=Airius<br />
 130                         &lt;RequireAny&gt;
 131                         <indent>
 132                             Require group sales<br />
 133                             Require ldap-attribute dept="sales"
 134                         </indent>
 135                         &lt;/RequireAny&gt;
 136                     </indent>
 137                     &lt;/RequireAll&gt;
 138                 </indent>
 139                 &lt;/RequireAny&gt;<br />
 140                 &lt;RequireNone&gt;
 141                 <indent>
 142                     Require group temps<br />
 143                     Require ldap-group cn=Temporary Employees,o=Airius
 144                 </indent>
 145                 &lt;/RequireNone&gt;
 146             </indent>
 147             &lt;/RequireAll&gt;
 148         </indent>
 149         &lt;/Directory&gt;
 150     </example>
 151 </section>
 152
 153 <section id="requiredirectives"><title>The Require Directives</title>
 154
 155   <p><module>mod_authz_core</module> provides some generic authorization
 156   providers which can be used with the
 157   <directive module="mod_authz_core">Require</directive> directive.</p>
 158
 159   <section id="reqenv"><title>Require env</title>
 160
 161     <p>The <code>env</code> provider allows access to the server
 162     to be controlled based on the existence of an <a
 163     href="../env.html">environment variable</a>. When <code>Require
 164     env <var>env-variable</var></code> is specified, then the request is
 165     allowed access if the environment variable <var>env-variable</var>
 166     exists. The server provides the ability to set environment
 167     variables in a flexible way based on characteristics of the client
 168     request using the directives provided by
 169     <module>mod_setenvif</module>. Therefore, this directive can be
 170     used to allow access based on such factors as the clients
 171     <code>User-Agent</code> (browser type), <code>Referer</code>, or
 172     other HTTP request header fields.</p>
 173
 174     <example><title>Example:</title>
 175       SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in<br />
 176       &lt;Directory /docroot&gt;<br />
 177       <indent>
 178         Require env let_me_in<br />
 179       </indent>
 180       &lt;/Directory&gt;
 181     </example>
 182
 183     <p>In this case, browsers with a user-agent string beginning
 184     with <code>KnockKnock/2.0</code> will be allowed access, and all
 185     others will be denied.</p>
 186
 187   </section>
 188
 189   <section id="reqall"><title>Require all</title>
 190
 191     <p>The <code>all</code> provider mimics the functionality the
 192     was previously provided by the 'Allow from all' and 'Deny from all'
 193     directives.  This provider can take one of two arguments which are
 194     'granted' or 'denied'.  The following examples will grant or deny
 195     access to all requests.</p>
 196
 197     <example>
 198     Require all granted<br />
 199     </example>
 200
 201     <example>
 202     Require all denied<br />
 203     </example>
 204
 205   </section>
 206
 207   <section id="reqmethod"><title>Require method</title>
 208
 209     <p>The <code>method</code> provider allows to use the HTTP method in
 210     authorization decisions. The GET and HEAD methods are treated as
 211     equivalent. The TRACE method is not available to this provider,
 212     use <directive module="core">TraceEnable</directive> instead.</p>
 213
 214     <p>The following example will only allow GET, HEAD, POST, and OPTIONS
 215     requests:</p>
 216
 217     <example>
 218         Require method GET POST OPTIONS<br />
 219     </example>
 220
 221     <p>The following example will allow GET, HEAD, POST, and OPTIONS
 222     requests without authentication, and require a valid user for all other
 223     methods:</p>
 224
 225     <example>
 226         &lt;RequireAny&gt;<br />
 227         &nbsp;Require method GET POST OPTIONS<br />
 228         &nbsp;Require valid-user<br />
 229         &lt;/RequireAny&gt;<br />
 230     </example>
 231
 232   </section>
 233
 234   <section id="reqexpr"><title>Require expr</title>
 235
 236   <p>The <code>expr</code> provider allows to base authorization
 237   decisions on arbitrary expressions.</p>
 238
 239     <example>
 240         Require expr %{TIME_HOUR} &gt;= 9 &amp; %{TIME_HOUR} &lt;= 17 <br />
 241     </example>
 242
 243   <p>The syntax is described in the <a href="../expr.html">ap_expr</a>
 244   documentation.</p>
 245
 246   </section>
 247
 248
 249 </section>
 250
 251 <directivesynopsis>
 252 <name>Require</name>
 253 <description>Tests whether an authenticated user is authorized by
 254 an authorization provider.</description>
 255 <syntax>Require [not] <var>entity-name</var>
 256     [<var>entity-name</var>] ...</syntax>
 257 <contextlist><context>directory</context><context>.htaccess</context>
 258 </contextlist>
 259 <override>AuthConfig</override>
 260
 261 <usage>
 262     <p>This directive tests whether an authenticated user is authorized
 263     according to a particular authorization provider and the specified
 264     restrictions. <module>mod_authz_core</module> provides the following
 265     generic authorization providers:</p>
 266
 267     <dl>
 268       <dt><code>Require all granted</code></dt>
 269       <dd>Access is allowed unconditionally.</dd>
 270
 271       <dt><code>Require all denied</code></dt>
 272       <dd>Access is denied unconditionally.</dd>
 273
 274       <dt><code>Require env <var>env-var</var> [<var>env-var</var>]
 275       ...</code></dt>
 276       <dd>Access is allowed only if one of the given environment variables is
 277           set.</dd>
 278
 279       <dt><code>Require method <var>http-method</var> [<var>http-method</var>]
 280       ...</code></dt>
 281       <dd>Access is allowed only for the given HTTP methods.</dd>
 282
 283       <dt><code>Require expr <var>expression</var> </code></dt>
 284       <dd>Access is allowed if <var>expression</var> evaluates to true.</dd>
 285     </dl>
 286
 287     <p>Some of the allowed syntaxes provided by <module>mod_authz_user</module>
 288        and <module>mod_authz_groupfile</module> are:</p>
 289
 290     <dl>
 291       <dt><code>Require user <var>userid</var> [<var>userid</var>]
 292       ...</code></dt>
 293       <dd>Only the named users can access the resource.</dd>
 294
 295       <dt><code>Require group <var>group-name</var> [<var>group-name</var>]
 296       ...</code></dt>
 297       <dd>Only users in the named groups can access the resource.</dd>
 298
 299       <dt><code>Require valid-user</code></dt>
 300       <dd>All valid users can access the resource.</dd>
 301     </dl>
 302
 303     <p>Other authorization modules that implement require options
 304     include <module>mod_authnz_ldap</module>,
 305     <module>mod_authz_dbm</module>, <module>mod_authz_dbd</module>,
 306     <module>mod_authz_host</module>,
 307     <module>mod_authz_owner</module> and <module>mod_ssl</module>.</p>
 308
 309     <p>In most cases, for a complete authentication and authorization
 310     configuration, <directive>Require</directive> must be accompanied by
 311     <directive module="mod_authn_core">AuthName</directive>, <directive
 312     module="mod_authn_core">AuthType</directive> and
 313     <directive module="mod_auth_basic">AuthBasicProvider</directive> or
 314     <directive module="mod_auth_digest">AuthDigestProvider</directive>
 315     directives, and directives such as
 316     <directive module="mod_authn_file">AuthUserFile</directive>
 317     and <directive module="mod_authz_groupfile">AuthGroupFile</directive> (to
 318     define users and groups) in order to work correctly. Example:</p>
 319
 320     <example>
 321        AuthType Basic<br />
 322        AuthName "Restricted Resource"<br />
 323        AuthBasicProvider file<br />
 324        AuthUserFile /web/users<br />
 325        AuthGroupFile /web/groups<br />
 326        Require group admin
 327     </example>
 328
 329     <p>Access controls which are applied in this way are effective for
 330     <strong>all</strong> methods. <strong>This is what is normally
 331     desired.</strong> If you wish to apply access controls only to
 332     specific methods, while leaving other methods unprotected, then
 333     place the <directive>Require</directive> statement into a
 334     <directive module="core" type="section">Limit</directive>
 335     section.</p>
 336
 337     <p>The result of the <directive>Require</directive> directive
 338     may be negated through the use of the
 339     <code>not</code> option.  As with the other negated authorization
 340     directive <directive type="section">RequireNone</directive>,
 341     when the <directive>Require</directive> directive is negated it can
 342     only fail or return a neutral result, and therefore may never
 343     independently authorize a request.</p>
 344
 345     <p>In the following example, all users in the <code>alpha</code>
 346     and <code>beta</code> groups are authorized, except for those who
 347     are also in the <code>reject</code> group.</p>
 348
 349     <example>
 350         &lt;Directory /www/docs&gt;
 351         <indent>
 352             &lt;RequireAll&gt;
 353             <indent>
 354                 Require group alpha beta<br />
 355                 Require not group reject
 356             </indent>
 357             &lt;/RequireAll&gt;
 358         </indent>
 359         &lt;/Directory&gt;
 360     </example>
 361
 362     <p>When multiple <directive>Require</directive> directives are
 363     used in a single
 364     <a href="../sections.html#mergin">configuration section</a>
 365     and are not contained in another authorization directive like
 366     <directive module="mod_authz_core" type="section">RequireAll</directive>,
 367     they are implicitly contained within a
 368     <directive module="mod_authz_core" type="section">RequireAny</directive>
 369     directive.  Thus the first one to authorize a user authorizes the
 370     entire request, and subsequent <directive>Require</directive> directives
 371     are ignored.</p>
 372 </usage>
 373
 374 <seealso><a href="../howto/auth.html">Authentication, Authorization,
 375     and Access Control</a></seealso>
 376 <seealso><a href="#logic">Authorization Containers</a></seealso>
 377 <seealso><module>mod_authn_core</module></seealso>
 378 <seealso><module>mod_authz_host</module></seealso>
 379 </directivesynopsis>
 380
 381 <directivesynopsis type="section">
 382 <name>RequireAll</name>
 383 <description>Enclose a group of authorization directives of which none
 384 must fail and at least one must succeed for the enclosing directive to
 385 succeed.</description>
 386 <syntax>&lt;RequireAll&gt; ... &lt;/RequireAll&gt;</syntax>
 387 <contextlist><context>directory</context><context>.htaccess</context>
 388 </contextlist>
 389 <override>AuthConfig</override>
 390
 391 <usage>
 392     <p><directive type="section">RequireAll</directive> and
 393     <code>&lt;/RequireAll&gt;</code> are used to enclose a group of
 394     authorization directives of which none must fail and at least one
 395     must succeed in order for
 396     the <directive type="section">RequireAll</directive> directive to
 397     succeed.</p>
 398
 399     <p>If none of the directives contained within the
 400     <directive type="section">RequireAll</directive> directive fails,
 401     and at least one succeeds, then the
 402     <directive type="section">RequireAll</directive> directive
 403     succeeds.  If none succeed and none fail, then it returns a
 404     neutral result.  In all other cases, it fails.</p>
 405 </usage>
 406
 407 <seealso><a href="#logic">Authorization Containers</a></seealso>
 408 <seealso><a href="../howto/auth.html">Authentication, Authorization,
 409     and Access Control</a></seealso>
 410
 411 </directivesynopsis>
 412
 413 <directivesynopsis type="section">
 414 <name>RequireAny</name>
 415 <description>Enclose a group of authorization directives of which one
 416 must succeed for the enclosing directive to succeed.</description>
 417 <syntax>&lt;RequireAny&gt; ... &lt;/RequireAny&gt;</syntax>
 418 <contextlist><context>directory</context><context>.htaccess</context>
 419 </contextlist>
 420 <override>AuthConfig</override>
 421
 422 <usage>
 423     <p><directive type="section">RequireAny</directive> and
 424     <code>&lt;/RequireAny&gt;</code> are used to enclose a group of
 425     authorization directives of which one must succeed in order for
 426     the <directive type="section">RequireAny</directive> directive to
 427     succeed.</p>
 428
 429     <p>If one or more of the directives contained within the
 430     <directive type="section">RequireAny</directive> directive succeed,
 431     then the <directive type="section">RequireAny</directive> directive
 432     succeeds.  If none succeed and none fail, then it returns a
 433     neutral result.  In all other cases, it fails.</p>
 434
 435     <note>Because negated authorization directives are unable to
 436     return a successful result, they can not significantly influence
 437     the result of a <directive type="section">RequireAny</directive>
 438     directive.  (At most they could cause the directive to fail in
 439     the case where they failed and all other directives returned a
 440     neutral value.)  Therefore negated authorization directives
 441     are not permitted within a <directive type="section">RequireAny</directive>
 442     directive.</note>
 443 </usage>
 444
 445 <seealso><a href="#logic">Authorization Containers</a></seealso>
 446 <seealso><a href="../howto/auth.html">Authentication, Authorization,
 447     and Access Control</a></seealso>
 448
 449 </directivesynopsis>
 450
 451 <directivesynopsis type="section">
 452 <name>RequireNone</name>
 453 <description>Enclose a group of authorization directives of which none
 454 must succeed for the enclosing directive to not fail.</description>
 455 <syntax>&lt;RequireNone&gt; ... &lt;/RequireNone&gt;</syntax>
 456 <contextlist><context>directory</context><context>.htaccess</context>
 457 </contextlist>
 458 <override>AuthConfig</override>
 459
 460 <usage>
 461     <p><directive type="section">RequireNone</directive> and
 462     <code>&lt;/RequireNone&gt;</code> are used to enclose a group of
 463     authorization directives of which none must succeed
 464     in order for the
 465     <directive type="section">RequireNone</directive> directive to
 466     not fail.</p>
 467
 468     <p>If one or more of the directives contained within the
 469     <directive type="section">RequireNone</directive> directive succeed,
 470     then the <directive type="section">RequireNone</directive> directive
 471     fails.  In all other cases, it returns a neutral result.  Thus as with
 472     the other negated authorization directive <code>Require not</code>,
 473     it can never independently
 474     authorize a request because it can never return a successful result.
 475     It can be used, however, to restrict the set of users who are
 476     authorized to access a resource.</p>
 477
 478     <note>Because negated authorization directives are unable to
 479     return a successful result, they can not significantly influence
 480     the result of a <directive type="section">RequireNone</directive>
 481     directive.  Therefore negated authorization directives
 482     are not permitted within a
 483     <directive type="section">RequireNone</directive> directive.</note>
 484 </usage>
 485
 486 <seealso><a href="#logic">Authorization Containers</a></seealso>
 487 <seealso><a href="../howto/auth.html">Authentication, Authorization,
 488     and Access Control</a></seealso>
 489
 490 </directivesynopsis>
 491
 492 <directivesynopsis>
 493 <name>AuthMerging</name>
 494 <description>Controls the manner in which each configuration section's
 495 authorization logic is combined with that of preceding configuration
 496 sections.</description>
 497 <syntax>AuthMerging Off | And | Or</syntax>
 498 <default>AuthMerging Off</default>
 499 <contextlist><context>directory</context><context>.htaccess</context>
 500 </contextlist>
 501 <override>AuthConfig</override>
 502
 503 <usage>
 504     <p>When authorization is enabled, it is normally inherited by each
 505     subsequent <a href="../sections.html#mergin">configuration section</a>,
 506     unless a different set of authorization directives are specified.
 507     This is the default action, which corresponds to an explicit setting
 508     of <code>AuthMerging Off</code>.</p>
 509
 510     <p>However, there may be circumstances in which is it desirable
 511     for a configuration section's authorization to be combined with
 512     that of its predecessor while configuration sections are being
 513     merged.  Two options are available for this case, <code>And</code>
 514     and <code>Or</code>.</p>
 515
 516     <p>When a configuration section contains <code>AuthMerging And</code>
 517     or <code>AuthMerging Or</code>,
 518     its authorization logic is combined with that of the nearest
 519     predecessor (according to the overall order of configuration sections)
 520     which also contains authorization logic as if the two sections
 521     were jointly contained within a
 522     <directive module="mod_authz_core" type="section">RequireAll</directive> or
 523     <directive module="mod_authz_core" type="section">RequireAny</directive>
 524     directive, respectively.</p>
 525
 526     <note>The setting of <directive>AuthMerging</directive> is not
 527     inherited outside of the configuration section in which it appears.
 528     In the following example, only users belonging to group <code>alpha</code>
 529     may access <code>/www/docs</code>.  Users belonging to either
 530     groups <code>alpha</code> or <code>beta</code> may access
 531     <code>/www/docs/ab</code>.  However, the default <code>Off</code>
 532     setting of <directive>AuthMerging</directive> applies to the
 533     <directive type="section" module="core">Directory</directive>
 534     configuration section for <code>/www/docs/ab/gamma</code>, so
 535     that section's authorization directives override those of the
 536     preceding sections.  Thus only users belong to the group
 537     <code>gamma</code> may access <code>/www/docs/ab/gamma</code>.</note>
 538
 539     <example>
 540         &lt;Directory /www/docs&gt;
 541         <indent>
 542             AuthType Basic<br />
 543             AuthName Documents<br />
 544             AuthBasicProvider file<br />
 545             AuthUserFile /usr/local/apache/passwd/passwords<br />
 546             Require group alpha
 547         </indent>
 548         &lt;/Directory&gt;<br />
 549         <br />
 550         &lt;Directory /www/docs/ab&gt;
 551         <indent>
 552             AuthMerging Or<br />
 553             Require group beta
 554         </indent>
 555         &lt;/Directory&gt;<br />
 556         <br />
 557         &lt;Directory /www/docs/ab/gamma&gt;
 558         <indent>
 559             Require group gamma
 560         </indent>
 561         &lt;/Directory&gt;
 562     </example>
 563 </usage>
 564
 565 </directivesynopsis>
 566
 567 <directivesynopsis type="section">
 568 <name>AuthzProviderAlias</name>
 569 <description>Enclose a group of directives that represent an
 570 extension of a base authorization provider and referenced by the specified
 571 alias</description>
 572 <syntax>&lt;AuthzProviderAlias <var>baseProvider Alias Require-Parameters</var>&gt;
 573 ... &lt;/AuthzProviderAlias&gt;
 574 </syntax>
 575 <contextlist><context>server config</context>
 576 </contextlist>
 577
 578 <usage>
 579     <p><directive type="section">AuthzProviderAlias</directive> and
 580     <code>&lt;/AuthzProviderAlias&gt;</code> are used to enclose a group of
 581     authorization directives that can be referenced by the alias name using the
 582     directive <directive module="mod_authz_core">Require</directive>.</p>
 583
 584 </usage>
 585 </directivesynopsis>
 586
 587 <directivesynopsis>
 588 <name>AuthzSendForbiddenOnFailure</name>
 589 <description>Send '403 FORBIDDEN' instead of '401 UNAUTHORIZED' if
 590 authentication succeeds but authorization fails
 591 </description>
 592 <syntax>AuthzSendForbiddenOnFailure On|Off</syntax>
 593 <default>AuthzSendForbiddenOnFailure Off</default>
 594 <contextlist><context>directory</context><context>.htaccess</context>
 595 </contextlist>
 596 <compatibility>Available in Apache HTTPD 2.3.11 and later</compatibility>
 597
 598 <usage>
 599     <p>If authentication succeeds but authorization fails, Apache HTTPD will
 600     respond with an HTTP response code of '401 UNAUTHORIZED' by default. This
 601     usually causes browsers to display the password dialogue to the user
 602     again, which is not wanted in all situations.
 603     <directive>AuthzSendForbiddenOnFailure</directive> allows to change the
 604     response code to '403 FORBIDDEN'.</p>
 605
 606     <note type="warning"><title>Security Warning</title>
 607     <p>Modifying the response in case of missing authorization weakens the
 608     security of the password, because it reveals to a possible attacker, that
 609     his guessed password was right.</p>
 610     </note>
 611 </usage>
 612 </directivesynopsis>
 613
 614
 615 </modulesynopsis>