]> granicus.if.org Git - apache/commitdiff
Broken markup in example
authorRich Bowen <rbowen@apache.org>
Thu, 17 Oct 2013 18:24:53 +0000 (18:24 +0000)
committerRich Bowen <rbowen@apache.org>
Thu, 17 Oct 2013 18:24:53 +0000 (18:24 +0000)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1533199 13f79535-47bb-0310-9956-ffa450edef68

docs/manual/mod/mod_auth_basic.html.en
docs/manual/mod/mod_macro.html.en
docs/manual/mod/mod_macro.xml
docs/manual/mod/mod_proxy_html.html.en
docs/manual/mod/mod_session_crypto.html.en

index 45153bf1edd35de542e2665e9b3dbc345ec36f04..215f45b75e48a4cb7eb5afcbc67ca419e217c334 100644 (file)
@@ -49,6 +49,7 @@
 <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">
@@ -189,6 +190,78 @@ username and password</td></tr>
     <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">
index 276b9051ced37503db13c306ce32b7e69faabbbf..5a4cd92ec3ef417e155cc0e02b605e66603993f3 100644 (file)
@@ -73,7 +73,7 @@ multiple similar virtual hosts:</p>
     DocumentRoot /var/www/vhosts/$name
     ErrorLog /var/log/httpd/$name.error_log
     CustomLog /var/log/httpd/$name.access_log combined
-&gt;/VirtualHost&gt;
+&lt;/VirtualHost&gt;
 &lt;/Macro&gt;
 </pre>
 
index c0da917f9ed65c12d3801b95239e4392f577f05f..f88cbf5416a27d9255e0e6aec9210f2fa7ec5b7a 100644 (file)
@@ -58,7 +58,7 @@ multiple similar virtual hosts:</p>
     DocumentRoot /var/www/vhosts/$name
     ErrorLog /var/log/httpd/$name.error_log
     CustomLog /var/log/httpd/$name.access_log combined
-&gt;/VirtualHost&gt;
+&lt;/VirtualHost&gt;
 &lt;/Macro&gt;
 </highlight>
 
index 2ffee791783639fa9af659218875bc0a875ed214..12684b1ce23519b9ce78a807818bfebf54d98ef7 100644 (file)
@@ -36,9 +36,21 @@ from Clients' networks in a proxy context.</td></tr>
 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>&lt;a href="http://appserver.example.com/foo/bar.html"&gt;foobar&lt;/a&gt;</code> to <code>&lt;a href="http://www.example.com/appserver/foo/bar.html"&gt;foobar&lt;/a&gt;</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>&lt;a href="http://appserver.example.com/foo/bar.html"&gt;foobar&lt;/a&gt;</code> to
+<code>&lt;a href="http://www.example.com/appserver/foo/bar.html"&gt;foobar&lt;/a&gt;</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>
index 63da434313a9b734223126977c25463326509970..8ff0687383fe8999f6ba5a907504fa8e919a47b5 100644 (file)
@@ -203,6 +203,19 @@ SessionCryptoPassphrase secret
     secret to the end of the list, and once rolled out completely to all servers, remove
     the first key from the start of the list.</p>
 
+    <p>If the value begins with exec: the resulting command will be executed and the
+    first line returned to standard output by the program will be used as the key.</p>
+<div class="example"><pre>
+#key used as-is
+SessionCryptoPassphrase secret
+
+#Run /path/to/program to get key
+SessionCryptoPassphrase exec:/path/to/program
+
+#Run /path/to/otherProgram and provide arguments
+SessionCryptoPassphrase "exec:/path/to/otherProgram argument1"
+</pre></div>
+
 
 </div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>