<li><img alt="" src="../images/down.gif" /> <a href="#authbasicauthoritative">AuthBasicAuthoritative</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#authbasicfake">AuthBasicFake</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#authbasicprovider">AuthBasicProvider</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#authbasicusedigestalgorithm">AuthBasicUseDigestAlgorithm</a></li>
</ul>
<h3>See also</h3>
<ul class="seealso">
<code class="module"><a href="../mod/mod_authn_file.html">mod_authn_file</a></code>, <code class="module"><a href="../mod/mod_authn_dbd.html">mod_authn_dbd</a></code>,
<code class="module"><a href="../mod/mod_authnz_ldap.html">mod_authnz_ldap</a></code> and <code class="module"><a href="../mod/mod_authn_socache.html">mod_authn_socache</a></code>.</p>
+</div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="directive-section"><h2><a name="AuthBasicUseDigestAlgorithm" id="AuthBasicUseDigestAlgorithm">AuthBasicUseDigestAlgorithm</a> <a name="authbasicusedigestalgorithm" id="authbasicusedigestalgorithm">Directive</a></h2>
+<table class="directive">
+<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Check passwords against the authentication providers as if
+Digest Authentication was in force instead of Basic Authentication.
+</td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>AuthBasicUseDigestAlgorithm MD5|Off</code></td></tr>
+<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>AuthBasicUseDigestAlgorithm Off</code></td></tr>
+<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>directory, .htaccess</td></tr>
+<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>AuthConfig</td></tr>
+<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Base</td></tr>
+<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_auth_basic</td></tr>
+<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Apache HTTP Server 2.4.7 and later</td></tr>
+</table>
+ <p>Normally, when using Basic Authentication, the providers listed in
+ <code class="directive"><a href="#authbasicprovider">AuthBasicProvider</a></code>
+ attempt to verify a user by checking their data stores for
+ a matching username and associated password. The stored passwords
+ are usually encrypted, but not necessarily so; each provider may
+ choose its own storage scheme for passwords.</p>
+
+ <p>When using <code class="directive"><a href="../mod/mod_auth_digest.html#authdigestprovider">AuthDigestProvider</a></code> and Digest
+ Authentication, providers perform a similar check to find a matching
+ username in their data stores. However, unlike in the Basic
+ Authentication case, the value associated with each stored username
+ must be an encrypted string composed from the username, realm name,
+ and password. (See
+ <a href="http://tools.ietf.org/html/rfc2617#section-3.2.2.2">
+ RFC 2617, Section 3.2.2.2</a> for more details on the format used
+ for this encrypted string.)</p>
+
+ <p>As a consequence of the difference in the stored values between
+ Basic and Digest Authentication, converting from Digest
+ Authentication to Basic Authentication generally requires that all
+ users be assigned new passwords, as their existing passwords cannot
+ be recovered from the password storage scheme imposed on those
+ providers which support Digest Authentication.</p>
+
+ <p>Setting the <code class="directive"><a href="#authbasicusedigestalgorithm">AuthBasicUseDigestAlgorithm</a></code> directive
+ to <code>MD5</code> will cause the user's Basic Authentication password
+ to be checked using the same encrypted format as for Digest
+ Authentication. First a string composed from the username, realm name,
+ and password is hashed with MD5; then the username and this encrypted
+ string are passed to the providers listed in
+ <code class="directive"><a href="#authbasicprovider">AuthBasicProvider</a></code>
+ as if
+ <code class="directive"><a href="../mod/mod_authn_core.html#authtype">AuthType</a></code>
+ was set to <code>Digest</code> and Digest Authentication was in force.
+ </p>
+
+ <p>Through the use of <code class="directive"><a href="#authbasicusedigestalgorithm">AuthBasicUseDigestAlgorithm</a></code>
+ a site may switch from Digest to Basic Authentication without
+ requiring users to be assigned new passwords.</p>
+
+ <div class="note">
+ The inverse process of switching from Basic to Digest
+ Authentication without assigning new passwords is generally
+ not possible. Only if the Basic Authentication passwords
+ have been stored in plain text or with a reversable encryption
+ scheme will it be possible to recover them and generate a
+ new data store following the Digest Authentication password
+ storage scheme.
+ </div>
+
+ <div class="note">
+ Only providers which support Digest Authentication will be able
+ to authenticate users when <code class="directive"><a href="#authbasicusedigestalgorithm">AuthBasicUseDigestAlgorithm</a></code>
+ is set to <code>MD5</code>. Use of other providers will result
+ in an error response and the client will be denied access.
+ </div>
+
</div>
</div>
<div class="bottomlang">
for earlier 2.x versions</td></tr></table>
<h3>Summary</h3>
- <p>This module provides an output filter to rewrite HTML links in a proxy situation, to ensure that links work for users outside the proxy. It serves the same purpose as Apache's ProxyPassReverse directive does for HTTP headers, and is an essential component of a reverse proxy.</p>
+<p>This module provides an output filter to rewrite HTML links in a
+proxy situation, to ensure that links work for users outside the proxy.
+It serves the same purpose as Apache's ProxyPassReverse directive does
+for HTTP headers, and is an essential component of a reverse proxy.</p>
-<p>For example, if a company has an application server at appserver.example.com that is only visible from within the company's internal network, and a public webserver <code>www.example.com</code>, they may wish to provide a gateway to the application server at <code>http://www.example.com/appserver/</code>. When the application server links to itself, those links need to be rewritten to work through the gateway. mod_proxy_html serves to rewrite <code><a href="http://appserver.example.com/foo/bar.html">foobar</a></code> to <code><a href="http://www.example.com/appserver/foo/bar.html">foobar</a></code> making it accessible from outside.</p>
+<p>For example, if a company has an application server at
+<code>appserver.example.com</code> that is only visible from within
+the company's internal network, and a public webserver
+<code>www.example.com</code>, they may wish to provide a gateway to the
+application server at <code>http://www.example.com/appserver/</code>.
+When the application server links to itself, those links need to be
+rewritten to work through the gateway. mod_proxy_html serves to rewrite
+<code><a href="http://appserver.example.com/foo/bar.html">foobar</a></code> to
+<code><a href="http://www.example.com/appserver/foo/bar.html">foobar</a></code>
+making it accessible from outside.</p>
<p>mod_proxy_html was originally developed at WebÞing, whose
extensive <a href="http://apache.webthing.com/mod_proxy_html/">documentation</a> may be useful to users.</p>