--- /dev/null
+<?xml version='1.0' encoding='UTF-8' ?>\r
+<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">\r
+<?xml-stylesheet type="text/xsl" href="../style/manual.es.xsl"?>\r
+<!-- $LastChangedRevision: 1738333 $ -->\r
+<!-- Translated by: Luis Gil de Bernabé Pfeiffer lgilbernabe [AT] apache.org-->\r
+<!-- Reviewed by: Sergio Ramos -->\r
+<!--\r
+ Licensed to the Apache Software Foundation (ASF) under one or more\r
+ contributor license agreements. See the NOTICE file distributed with\r
+ this work for additional information regarding copyright ownership.\r
+ The ASF licenses this file to You under the Apache License, Version 2.0\r
+ (the "License"); you may not use this file except in compliance with\r
+ the License. You may obtain a copy of the License at\r
+\r
+ http://www.apache.org/licenses/LICENSE-2.0\r
+\r
+ Unless required by applicable law or agreed to in writing, software\r
+ distributed under the License is distributed on an "AS IS" BASIS,\r
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\r
+ See the License for the specific language governing permissions and\r
+ limitations under the License.\r
+-->\r
+\r
+<manualpage metafile="auth.xml.meta">\r
+<parentdocument href="./">How-To / Tutoriales</parentdocument>\r
+\r
+<title>Autenticación y Autorización</title>\r
+\r
+<summary>\r
+ <p>Autenticación es cualquier proceso por el cuál se verifica que uno es \r
+ quien dice ser. Autorización es cualquier proceso en el cuál cualquiera\r
+ está permitido a estar donde se quiera, o tener información la cuál se\r
+ quiera tener.\r
+ </p>\r
+\r
+ <p>Para información de control de acceso de forma genérica visite<a href="access.html">How to de Control de Acceso</a>.</p>\r
+</summary>\r
+\r
+<section id="related"><title>Módulos y Directivas Relacionados</title>\r
+\r
+<p>Hay tres tipos de módulos involucrados en los procesos de la autenticación \r
+ y autorización. Normalmente deberás escoger al menos un módulo de cada grupo.</p>\r
+\r
+<ul>\r
+ <li>Modos de Autenticación (consulte la directiva\r
+ <directive module="mod_authn_core">AuthType</directive> )\r
+ <ul>\r
+ <li><module>mod_auth_basic</module></li>\r
+ <li><module>mod_auth_digest</module></li>\r
+ </ul>\r
+ </li>\r
+ <li>Proveedor de Autenticación (consulte la directiva\r
+ <directive module="mod_auth_basic">AuthBasicProvider</directive> y\r
+ <directive module="mod_auth_digest">AuthDigestProvider</directive>)\r
+\r
+ <ul>\r
+ <li><module>mod_authn_anon</module></li>\r
+ <li><module>mod_authn_dbd</module></li>\r
+ <li><module>mod_authn_dbm</module></li>\r
+ <li><module>mod_authn_file</module></li>\r
+ <li><module>mod_authnz_ldap</module></li>\r
+ <li><module>mod_authn_socache</module></li>\r
+ </ul>\r
+ </li>\r
+ <li>Autorización (consulte la directiva\r
+ <directive module="mod_authz_core">Require</directive>)\r
+ <ul>\r
+ <li><module>mod_authnz_ldap</module></li>\r
+ <li><module>mod_authz_dbd</module></li>\r
+ <li><module>mod_authz_dbm</module></li>\r
+ <li><module>mod_authz_groupfile</module></li>\r
+ <li><module>mod_authz_host</module></li>\r
+ <li><module>mod_authz_owner</module></li>\r
+ <li><module>mod_authz_user</module></li>\r
+ </ul>\r
+ </li>\r
+</ul>\r
+\r
+ <p>A parte de éstos módulos, también están\r
+ <module>mod_authn_core</module> y\r
+ <module>mod_authz_core</module>. Éstos módulos implementan las directivas \r
+ esenciales que son el centro de todos los módulos de autenticación.</p>\r
+\r
+ <p>El módulo <module>mod_authnz_ldap</module> es tanto un proveedor de \r
+ autenticación como de autorización. El módulo\r
+ <module>mod_authz_host</module> proporciona autorización y control de acceso\r
+ basado en el nombre del Host, la dirección IP o características de la propia\r
+ petición, pero no es parte del sistema proveedor de \r
+ autenticación. Para tener compatibilidad inversa con el mod_access, \r
+ hay un nuevo modulo llamado <module>mod_access_compat</module>.</p>\r
+\r
+ <p>También puedes mirar al howto de <a\r
+ href="access.html">Control de Acceso </a>, donde se plantean varias formas del control de acceso al servidor.</p>\r
+\r
+</section>\r
+\r
+<section id="introduction"><title>Introducción</title>\r
+ <p>If you have information on your web site that is sensitive\r
+ or intended for only a small group of people, the techniques in\r
+ this article will help you make sure that the people that see\r
+ those pages are the people that you wanted to see them.</p>\r
+\r
+ <p>This article covers the "standard" way of protecting parts\r
+ of your web site that most of you are going to use.</p>\r
+\r
+ <note><title>Note:</title>\r
+ <p>If your data really needs to be secure, consider using\r
+ <module>mod_ssl</module> in addition to any authentication.</p>\r
+ </note>\r
+</section>\r
+\r
+<section id="theprerequisites"><title>The Prerequisites</title>\r
+ <p>The directives discussed in this article will need to go\r
+ either in your main server configuration file (typically in a\r
+ <directive module="core" type="section">Directory</directive> section), or\r
+ in per-directory configuration files (<code>.htaccess</code> files).</p>\r
+\r
+ <p>If you plan to use <code>.htaccess</code> files, you will\r
+ need to have a server configuration that permits putting\r
+ authentication directives in these files. This is done with the\r
+ <directive module="core">AllowOverride</directive> directive, which\r
+ specifies which directives, if any, may be put in per-directory\r
+ configuration files.</p>\r
+\r
+ <p>Since we're talking here about authentication, you will need\r
+ an <directive module="core">AllowOverride</directive> directive like the\r
+ following:</p>\r
+\r
+ <highlight language="config">\r
+AllowOverride AuthConfig\r
+ </highlight>\r
+\r
+ <p>Or, if you are just going to put the directives directly in\r
+ your main server configuration file, you will of course need to\r
+ have write permission to that file.</p>\r
+\r
+ <p>And you'll need to know a little bit about the directory\r
+ structure of your server, in order to know where some files are\r
+ kept. This should not be terribly difficult, and I'll try to\r
+ make this clear when we come to that point.</p>\r
+\r
+ <p>You will also need to make sure that the modules\r
+ <module>mod_authn_core</module> and <module>mod_authz_core</module>\r
+ have either been built into the httpd binary or loaded by the\r
+ httpd.conf configuration file. Both of these modules provide core\r
+ directives and functionality that are critical to the configuration\r
+ and use of authentication and authorization in the web server.</p>\r
+</section>\r
+\r
+<section id="gettingitworking"><title>Getting it working</title>\r
+ <p>Here's the basics of password protecting a directory on your\r
+ server.</p>\r
+\r
+ <p>First, you need to create a password file. Exactly how you do\r
+ this will vary depending on what authentication provider you have\r
+ chosen. More on that later. To start with, we'll use a text password\r
+ file.</p>\r
+\r
+ <p>This file should be\r
+ placed somewhere not accessible from the web. This is so that\r
+ folks cannot download the password file. For example, if your\r
+ documents are served out of <code>/usr/local/apache/htdocs</code>, you\r
+ might want to put the password file(s) in\r
+ <code>/usr/local/apache/passwd</code>.</p>\r
+\r
+ <p>To create the file, use the <program>htpasswd</program> utility that\r
+ came with Apache. This will be located in the <code>bin</code> directory\r
+ of wherever you installed Apache. If you have installed Apache from\r
+ a third-party package, it may be in your execution path.</p>\r
+\r
+ <p>To create the file, type:</p>\r
+\r
+ <example>\r
+ htpasswd -c /usr/local/apache/passwd/passwords rbowen\r
+ </example>\r
+\r
+ <p><program>htpasswd</program> will ask you for the password, and\r
+ then ask you to type it again to confirm it:</p>\r
+\r
+ <example>\r
+ # htpasswd -c /usr/local/apache/passwd/passwords rbowen<br />\r
+ New password: mypassword<br />\r
+ Re-type new password: mypassword<br />\r
+ Adding password for user rbowen\r
+ </example>\r
+\r
+ <p>If <program>htpasswd</program> is not in your path, of course\r
+ you'll have to type the full path to the file to get it to run.\r
+ With a default installation, it's located at\r
+ <code>/usr/local/apache2/bin/htpasswd</code></p>\r
+\r
+ <p>Next, you'll need to configure the server to request a\r
+ password and tell the server which users are allowed access.\r
+ You can do this either by editing the <code>httpd.conf</code>\r
+ file or using an <code>.htaccess</code> file. For example, if\r
+ you wish to protect the directory\r
+ <code>/usr/local/apache/htdocs/secret</code>, you can use the\r
+ following directives, either placed in the file\r
+ <code>/usr/local/apache/htdocs/secret/.htaccess</code>, or\r
+ placed in <code>httpd.conf</code> inside a <Directory\r
+ "/usr/local/apache/htdocs/secret"> section.</p>\r
+\r
+ <highlight language="config">\r
+AuthType Basic\r
+AuthName "Restricted Files"\r
+# (Following line optional)\r
+AuthBasicProvider file\r
+AuthUserFile "/usr/local/apache/passwd/passwords"\r
+Require user rbowen\r
+ </highlight>\r
+\r
+ <p>Let's examine each of those directives individually. The <directive\r
+ module="mod_authn_core">AuthType</directive> directive selects\r
+ that method that is used to authenticate the user. The most\r
+ common method is <code>Basic</code>, and this is the method\r
+ implemented by <module>mod_auth_basic</module>. It is important to be aware,\r
+ however, that Basic authentication sends the password from the client to\r
+ the server unencrypted. This method should therefore not be used for\r
+ highly sensitive data, unless accompanied by <module>mod_ssl</module>.\r
+ Apache supports one other authentication method:\r
+ <code>AuthType Digest</code>. This method is implemented by <module\r
+ >mod_auth_digest</module> and was intended to be more secure. This is no\r
+ longer the case and the connection should be encrypted with <module\r
+ >mod_ssl</module> instead.</p>\r
+\r
+ <p>The <directive module="mod_authn_core">AuthName</directive> directive sets\r
+ the <dfn>Realm</dfn> to be used in the authentication. The realm serves\r
+ two major functions. First, the client often presents this information to\r
+ the user as part of the password dialog box. Second, it is used by the\r
+ client to determine what password to send for a given authenticated\r
+ area.</p>\r
+\r
+ <p>So, for example, once a client has authenticated in the\r
+ <code>"Restricted Files"</code> area, it will automatically\r
+ retry the same password for any area on the same server that is\r
+ marked with the <code>"Restricted Files"</code> Realm.\r
+ Therefore, you can prevent a user from being prompted more than\r
+ once for a password by letting multiple restricted areas share\r
+ the same realm. Of course, for security reasons, the client\r
+ will always need to ask again for the password whenever the\r
+ hostname of the server changes.</p>\r
+\r
+ <p>The <directive\r
+ module="mod_auth_basic">AuthBasicProvider</directive> is,\r
+ in this case, optional, since <code>file</code> is the default value\r
+ for this directive. You'll need to use this directive if you are\r
+ choosing a different source for authentication, such as\r
+ <module>mod_authn_dbm</module> or <module>mod_authn_dbd</module>.</p>\r
+\r
+ <p>The <directive module="mod_authn_file">AuthUserFile</directive>\r
+ directive sets the path to the password file that we just\r
+ created with <program>htpasswd</program>. If you have a large number\r
+ of users, it can be quite slow to search through a plain text\r
+ file to authenticate the user on each request. Apache also has\r
+ the ability to store user information in fast database files.\r
+ The <module>mod_authn_dbm</module> module provides the <directive\r
+ module="mod_authn_dbm">AuthDBMUserFile</directive> directive. These\r
+ files can be created and manipulated with the <program>\r
+ dbmmanage</program> and <program>htdbm</program> programs. Many\r
+ other types of authentication options are available from third\r
+ party modules in the <a\r
+ href="http://modules.apache.org/">Apache Modules\r
+ Database</a>.</p>\r
+\r
+ <p>Finally, the <directive module="mod_authz_core">Require</directive>\r
+ directive provides the authorization part of the process by\r
+ setting the user that is allowed to access this region of the\r
+ server. In the next section, we discuss various ways to use the\r
+ <directive module="mod_authz_core">Require</directive> directive.</p>\r
+</section>\r
+\r
+<section id="lettingmorethanonepersonin"><title>Letting more than one\r
+person in</title>\r
+ <p>The directives above only let one person (specifically\r
+ someone with a username of <code>rbowen</code>) into the\r
+ directory. In most cases, you'll want to let more than one\r
+ person in. This is where the <directive module="mod_authz_groupfile"\r
+ >AuthGroupFile</directive> comes in.</p>\r
+\r
+ <p>If you want to let more than one person in, you'll need to\r
+ create a group file that associates group names with a list of\r
+ users in that group. The format of this file is pretty simple,\r
+ and you can create it with your favorite editor. The contents\r
+ of the file will look like this:</p>\r
+\r
+ <example>\r
+ GroupName: rbowen dpitts sungo rshersey\r
+ </example>\r
+\r
+ <p>That's just a list of the members of the group in a long\r
+ line separated by spaces.</p>\r
+\r
+ <p>To add a user to your already existing password file,\r
+ type:</p>\r
+\r
+ <example>\r
+ htpasswd /usr/local/apache/passwd/passwords dpitts\r
+ </example>\r
+\r
+ <p>You'll get the same response as before, but it will be\r
+ appended to the existing file, rather than creating a new file.\r
+ (It's the <code>-c</code> that makes it create a new password\r
+ file).</p>\r
+\r
+ <p>Now, you need to modify your <code>.htaccess</code> file to\r
+ look like the following:</p>\r
+\r
+ <highlight language="config">\r
+AuthType Basic\r
+AuthName "By Invitation Only"\r
+# Optional line:\r
+AuthBasicProvider file\r
+AuthUserFile "/usr/local/apache/passwd/passwords"\r
+AuthGroupFile "/usr/local/apache/passwd/groups"\r
+Require group GroupName\r
+ </highlight>\r
+\r
+ <p>Now, anyone that is listed in the group <code>GroupName</code>,\r
+ and has an entry in the <code>password</code> file, will be let in, if\r
+ they type the correct password.</p>\r
+\r
+ <p>There's another way to let multiple users in that is less\r
+ specific. Rather than creating a group file, you can just use\r
+ the following directive:</p>\r
+\r
+ <highlight language="config">\r
+Require valid-user\r
+ </highlight>\r
+\r
+ <p>Using that rather than the <code>Require user rbowen</code>\r
+ line will allow anyone in that is listed in the password file,\r
+ and who correctly enters their password. You can even emulate\r
+ the group behavior here, by just keeping a separate password\r
+ file for each group. The advantage of this approach is that\r
+ Apache only has to check one file, rather than two. The\r
+ disadvantage is that you have to maintain a bunch of password\r
+ files, and remember to reference the right one in the\r
+ <directive module="mod_authn_file">AuthUserFile</directive> directive.</p>\r
+</section>\r
+\r
+<section id="possibleproblems"><title>Possible problems</title>\r
+ <p>Because of the way that Basic authentication is specified,\r
+ your username and password must be verified every time you\r
+ request a document from the server. This is even if you're\r
+ reloading the same page, and for every image on the page (if\r
+ they come from a protected directory). As you can imagine, this\r
+ slows things down a little. The amount that it slows things\r
+ down is proportional to the size of the password file, because\r
+ it has to open up that file, and go down the list of users\r
+ until it gets to your name. And it has to do this every time a\r
+ page is loaded.</p>\r
+\r
+ <p>A consequence of this is that there's a practical limit to\r
+ how many users you can put in one password file. This limit\r
+ will vary depending on the performance of your particular\r
+ server machine, but you can expect to see slowdowns once you\r
+ get above a few hundred entries, and may wish to consider a\r
+ different authentication method at that time.</p>\r
+</section>\r
+\r
+<section id="dbmdbd"><title>Alternate password storage</title>\r
+\r
+ <p>Because storing passwords in plain text files has the above\r
+ problems, you may wish to store your passwords somewhere else, such\r
+ as in a database.</p>\r
+\r
+ <p><module>mod_authn_dbm</module> and <module>mod_authn_dbd</module> are two\r
+ modules which make this possible. Rather than selecting <code><directive\r
+ module="mod_auth_basic">AuthBasicProvider</directive> file</code>, instead\r
+ you can choose <code>dbm</code> or <code>dbd</code> as your storage\r
+ format.</p>\r
+\r
+ <p>To select a dbm file rather than a text file, for example:</p>\r
+\r
+ <highlight language="config">\r
+<Directory "/www/docs/private">\r
+ AuthName "Private"\r
+ AuthType Basic\r
+ AuthBasicProvider dbm\r
+ AuthDBMUserFile "/www/passwords/passwd.dbm"\r
+ Require valid-user\r
+</Directory>\r
+ </highlight>\r
+\r
+ <p>Other options are available. Consult the\r
+ <module>mod_authn_dbm</module> documentation for more details.</p>\r
+</section>\r
+\r
+<section id="multprovider"><title>Using multiple providers</title>\r
+\r
+ <p>With the introduction of the new provider based authentication and\r
+ authorization architecture, you are no longer locked into a single\r
+ authentication or authorization method. In fact any number of the\r
+ providers can be mixed and matched to provide you with exactly the\r
+ scheme that meets your needs. In the following example, both the\r
+ file and LDAP based authentication providers are being used.</p>\r
+\r
+ <highlight language="config">\r
+<Directory "/www/docs/private">\r
+ AuthName "Private"\r
+ AuthType Basic\r
+ AuthBasicProvider file ldap\r
+ AuthUserFile "/usr/local/apache/passwd/passwords"\r
+ AuthLDAPURL ldap://ldaphost/o=yourorg\r
+ Require valid-user\r
+</Directory>\r
+ </highlight>\r
+\r
+ <p>In this example the file provider will attempt to authenticate\r
+ the user first. If it is unable to authenticate the user, the LDAP\r
+ provider will be called. This allows the scope of authentication\r
+ to be broadened if your organization implements more than\r
+ one type of authentication store. Other authentication and authorization\r
+ scenarios may include mixing one type of authentication with a\r
+ different type of authorization. For example, authenticating against\r
+ a password file yet authorizing against an LDAP directory.</p>\r
+\r
+ <p>Just as multiple authentication providers can be implemented, multiple\r
+ authorization methods can also be used. In this example both file group\r
+ authorization as well as LDAP group authorization is being used.</p>\r
+\r
+ <highlight language="config">\r
+<Directory "/www/docs/private">\r
+ AuthName "Private"\r
+ AuthType Basic\r
+ AuthBasicProvider file\r
+ AuthUserFile "/usr/local/apache/passwd/passwords"\r
+ AuthLDAPURL ldap://ldaphost/o=yourorg\r
+ AuthGroupFile "/usr/local/apache/passwd/groups"\r
+ Require group GroupName\r
+ Require ldap-group cn=mygroup,o=yourorg\r
+</Directory>\r
+ </highlight>\r
+\r
+ <p>To take authorization a little further, authorization container\r
+ directives such as\r
+ <directive module="mod_authz_core" type="section">RequireAll</directive>\r
+ and\r
+ <directive module="mod_authz_core" type="section">RequireAny</directive>\r
+ allow logic to be applied so that the order in which authorization\r
+ is handled can be completely controlled through the configuration.\r
+ See <a href="../mod/mod_authz_core.html#logic">Authorization\r
+ Containers</a> for an example of how they may be applied.</p>\r
+\r
+</section>\r
+\r
+<section id="beyond"><title>Beyond just authorization</title>\r
+\r
+ <p>The way that authorization can be applied is now much more flexible\r
+ than just a single check against a single data store. Ordering, logic\r
+ and choosing how authorization will be done is now possible.</p>\r
+\r
+ <section id="authandororder"><title>Applying logic and ordering</title>\r
+ <p>Controlling how and in what order authorization will be applied\r
+ has been a bit of a mystery in the past. In Apache 2.2 a provider-based\r
+ authentication mechanism was introduced to decouple the actual\r
+ authentication process from authorization and supporting functionality.\r
+ One of the side benefits was that authentication providers could be\r
+ configured and called in a specific order which didn't depend on the\r
+ load order of the auth module itself. This same provider based mechanism\r
+ has been brought forward into authorization as well. What this means is\r
+ that the <directive module="mod_authz_core">Require</directive> directive\r
+ not only specifies which authorization methods should be used, it also\r
+ specifies the order in which they are called. Multiple authorization\r
+ methods are called in the same order in which the\r
+ <directive module="mod_authz_core">Require</directive> directives\r
+ appear in the configuration.</p>\r
+\r
+ <p>With the introduction of authorization container directives\r
+ such as\r
+ <directive module="mod_authz_core" type="section">RequireAll</directive>\r
+ and\r
+ <directive module="mod_authz_core" type="section">RequireAny</directive>,\r
+ the configuration also has control over when the\r
+ authorization methods are called and what criteria determines when\r
+ access is granted. See\r
+ <a href="../mod/mod_authz_core.html#logic">Authorization Containers</a>\r
+ for an example of how they may be used to express complex\r
+ authorization logic.</p>\r
+\r
+ <p>By default all\r
+ <directive module="mod_authz_core">Require</directive>\r
+ directives are handled as though contained within a\r
+ <directive module="mod_authz_core" type="section">RequireAny</directive>\r
+ container directive. In other words, if\r
+ any of the specified authorization methods succeed, then authorization\r
+ is granted.</p>\r
+\r
+ </section>\r
+\r
+ <section id="reqaccessctrl"><title>Using authorization providers for access control</title>\r
+ <p>Authentication by username and password is only part of the\r
+ story. Frequently you want to let people in based on something\r
+ other than who they are. Something such as where they are\r
+ coming from.</p>\r
+\r
+ <p>The authorization providers <code>all</code>,\r
+ <code>env</code>, <code>host</code> and <code>ip</code> let you\r
+ allow or deny access based on other host based criteria such as\r
+ host name or ip address of the machine requesting a\r
+ document.</p>\r
+\r
+ <p>The usage of these providers is specified through the\r
+ <directive module="mod_authz_core">Require</directive> directive.\r
+ This directive registers the authorization providers\r
+ that will be called during the authorization stage of the request\r
+ processing. For example:</p>\r
+\r
+ <highlight language="config">\r
+Require ip <var>address</var>\r
+ </highlight>\r
+\r
+ <p>where <var>address</var> is an IP address (or a partial IP\r
+ address) or:</p>\r
+\r
+ <highlight language="config">\r
+Require host <var>domain_name</var>\r
+ </highlight>\r
+\r
+ <p>where <var>domain_name</var> is a fully qualified domain name\r
+ (or a partial domain name); you may provide multiple addresses or\r
+ domain names, if desired.</p>\r
+\r
+ <p>For example, if you have someone spamming your message\r
+ board, and you want to keep them out, you could do the\r
+ following:</p>\r
+\r
+ <highlight language="config">\r
+<RequireAll>\r
+ Require all granted\r
+ Require not ip 10.252.46.165\r
+</RequireAll>\r
+ </highlight>\r
+\r
+ <p>Visitors coming from that address will not be able to see\r
+ the content covered by this directive. If, instead, you have a\r
+ machine name, rather than an IP address, you can use that.</p>\r
+\r
+ <highlight language="config">\r
+<RequireAll>\r
+ Require all granted\r
+ Require not host host.example.com\r
+</RequireAll>\r
+ </highlight>\r
+\r
+ <p>And, if you'd like to block access from an entire domain,\r
+ you can specify just part of an address or domain name:</p>\r
+\r
+ <highlight language="config">\r
+<RequireAll>\r
+ Require all granted\r
+ Require not ip 192.168.205\r
+ Require not host phishers.example.com moreidiots.example\r
+ Require not host ke\r
+</RequireAll>\r
+ </highlight>\r
+\r
+ <p>Using <directive module="mod_authz_core" type="section">RequireAll</directive>\r
+ with multiple <directive module="mod_authz_core"\r
+ type="section">Require</directive> directives, each negated with <code>not</code>,\r
+ will only allow access, if all of negated conditions are true. In other words,\r
+ access will be blocked, if any of the negated conditions fails.</p>\r
+\r
+ </section>\r
+\r
+ <section id="filesystem"><title>Access Control backwards compatibility</title>\r
+ <p>One of the side effects of adopting a provider based mechanism for\r
+ authentication is that the previous access control directives\r
+ <directive module="mod_access_compat">Order</directive>,\r
+ <directive module="mod_access_compat">Allow</directive>,\r
+ <directive module="mod_access_compat">Deny</directive> and\r
+ <directive module="mod_access_compat">Satisfy</directive> are no longer needed.\r
+ However to provide backwards compatibility for older configurations, these\r
+ directives have been moved to the <module>mod_access_compat</module> module.</p>\r
+\r
+ <note type="warning"><title>Note</title>\r
+ <p>The directives provided by <module>mod_access_compat</module> have\r
+ been deprecated by <module>mod_authz_host</module>.\r
+ Mixing old directives like <directive\r
+ module="mod_access_compat">Order</directive>, <directive\r
+ module="mod_access_compat">Allow</directive> or <directive\r
+ module="mod_access_compat">Deny</directive> with new ones like\r
+ <directive module="mod_authz_core">Require</directive> is technically possible\r
+ but discouraged. The <module>mod_access_compat</module> module was created to support\r
+ configurations containing only old directives to facilitate the 2.4 upgrade.\r
+ Please check the <a href="../upgrading.html">upgrading</a> guide for more\r
+ information.\r
+ </p>\r
+ </note>\r
+ </section>\r
+\r
+</section>\r
+\r
+<section id="socache"><title>Authentication Caching</title>\r
+ <p>There may be times when authentication puts an unacceptable load\r
+ on a provider or on your network. This is most likely to affect users\r
+ of <module>mod_authn_dbd</module> (or third-party/custom providers).\r
+ To deal with this, HTTPD 2.3/2.4 introduces a new caching provider\r
+ <module>mod_authn_socache</module> to cache credentials and reduce\r
+ the load on the origin provider(s).</p>\r
+ <p>This may offer a substantial performance boost to some users.</p>\r
+</section>\r
+\r
+<section id="moreinformation"><title>More information</title>\r
+ <p>You should also read the documentation for\r
+ <module>mod_auth_basic</module> and <module>mod_authz_host</module>\r
+ which contain some more information about how this all works. The\r
+ directive <directive type="section"\r
+ module="mod_authn_core">AuthnProviderAlias</directive> can also help\r
+ in simplifying certain authentication configurations.</p>\r
+\r
+ <p>The various ciphers supported by Apache for authentication data are\r
+ explained in <a href="../misc/password_encryptions.html">Password\r
+ Encryptions</a>.</p>\r
+\r
+ <p>And you may want to look at the <a href="access.html">Access\r
+ Control</a> howto, which discusses a number of related topics.</p>\r
+\r
+</section>\r
+\r
+</manualpage>\r
projects / apache / commitdiff