diff options
Diffstat (limited to 'docs/manual/mod')
| -rw-r--r-- | docs/manual/mod/mod_auth_form.html.en | 47 | ||||
| -rw-r--r-- | docs/manual/mod/mod_auth_form.xml | 47 | ||||
| -rw-r--r-- | docs/manual/mod/mod_auth_form.xml.meta | 1 | ||||
| -rw-r--r-- | docs/manual/mod/mod_session.html.en | 8 | ||||
| -rw-r--r-- | docs/manual/mod/mod_session.xml | 8 | ||||
| -rw-r--r-- | docs/manual/mod/mod_session.xml.meta | 1 |
6 files changed, 54 insertions, 58 deletions
diff --git a/docs/manual/mod/mod_auth_form.html.en b/docs/manual/mod/mod_auth_form.html.en index c2abb2d638..9411600f90 100644 --- a/docs/manual/mod/mod_auth_form.html.en +++ b/docs/manual/mod/mod_auth_form.html.en @@ -44,16 +44,16 @@ HTML login form can provide a much friendlier experience for end users. </p> - <p>HTTP Basic authentication is provided by - <code class="module"><a href="../mod/mod_auth_basic.html">mod_auth_basic</a></code>, and HTTP Digest Authentication is + <p>HTTP basic authentication is provided by + <code class="module"><a href="../mod/mod_auth_basic.html">mod_auth_basic</a></code>, and HTTP digest authentication is provided by <code class="module"><a href="../mod/mod_auth_digest.html">mod_auth_digest</a></code>. This module should - usually be combined with at least one authentication module + be combined with at least one authentication module such as <code class="module"><a href="../mod/mod_authn_file.html">mod_authn_file</a></code> and one authorization module such as <code class="module"><a href="../mod/mod_authz_user.html">mod_authz_user</a></code>.</p> <p>Once the user has been successfully authenticated, the user's login - details will be stored in a suitably configured <strong>session</strong>, - as provided by the <code class="module"><a href="../mod/mod_session.html">mod_session</a></code> module.</p> + details will be stored in a session provided by <code class="module"><a href="../mod/mod_session.html">mod_session</a></code>. + </p> </div> <div id="quickview"><h3 class="directives">Directives</h3> @@ -179,8 +179,8 @@ <p>The URLs specified by the <code class="directive"><a href="#authformloginrequiredlocation">AuthFormLoginRequiredLocation</a></code> directive will typically point to a page explaining to the user that their login attempt was unsuccessful, and they - should try again, while the <code class="directive"><a href="#authformloginsuccesslocation">AuthFormLoginSuccessLocation</a></code> - directive specifies the URL the user should be redirected to on success.</p> + should try again. The <code class="directive"><a href="#authformloginsuccesslocation">AuthFormLoginSuccessLocation</a></code> + directive specifies the URL the user should be redirected to upon successful login.</p> <p>Alternatively, the URL to redirect the user to on success can be embedded within the login form, as in the example below. As a result, the same <var>form-login-handler</var> can be @@ -216,15 +216,15 @@ session is in force, and the session times out in the middle of the user request. The user can be re-authenticated in place, and they can continue where they left off.</p> - <p>When a page protected by <code class="module"><a href="../mod/mod_auth_form.html">mod_auth_form</a></code> is accessed, and the user is - not logged in, and no <code class="directive"><a href="#authformloginrequiredlocation">AuthFormLoginRequiredLocation</a></code> - directive is specified as described in the section above, an <var>HTTP_UNAUTHORIZED</var> - status code is returned to the browser in the normal way indicating to the user that - they are not authorised to view the page.</p> + <p>If a non-authenticated user attempts to access a page protected by + <code class="module"><a href="../mod/mod_auth_form.html">mod_auth_form</a></code> that isn't configured with a + <code class="directive"><a href="#authformloginrequiredlocation">AuthFormLoginRequiredLocation</a></code> directive, + a <var>HTTP_UNAUTHORIZED</var> status code is returned to the browser indicating to the user + that they are not authorized to view the page.</p> <p>To configure inline authentication, the administrator overrides the error document - returned by the <var>HTTP_UNAUTHORIZED</var> status code with a custom error document, - containing the login form, as follows.</p> + returned by the <var>HTTP_UNAUTHORIZED</var> status code with a custom error document + containing the login form, as follows:</p> <div class="example"><h3>Basic inline example</h3><p><code> AuthFormProvider file<br /> @@ -238,9 +238,8 @@ SessionCryptoPassphrase secret<br /> </code></p></div> - <p>The error document file should contain the login form used to log in, as - per the example below. The key difference in this form is that the HTML - form action is left blank. This has the effect of submitting the form to + <p>The error document page should contain a login form with an empty action property, + as per the example below. This has the effect of submitting the form to the original protected URL, without the page having to know what that URL is.</p> @@ -272,7 +271,7 @@ end user.</p> <p><code class="module"><a href="../mod/mod_auth_form.html">mod_auth_form</a></code> addresses this by allowing the method and body - of the original request to be embedded in the login form, and if authentication + of the original request to be embedded in the login form. If authentication is successful, the original method and body will be retried by Apache, preserving the state of the original request.</p> @@ -298,7 +297,7 @@ <p>One option is to use the <code class="module"><a href="../mod/mod_include.html">mod_include</a></code> module along with the <code class="directive"><a href="../mod/core.html#keptbodysize">KeptBodySize</a></code> directive, along with a suitable - CGI script, to embed the variables in the form.</p> + CGI script to embed the variables in the form.</p> <p>Another option is to render the login form using a CGI script or other dynamic technology.</p> @@ -333,12 +332,12 @@ SessionCryptoPassphrase secret<br /> </code></p></div> - <p>Note that logging a user out does not delete the session, it merely removes + <p>Note that logging a user out does not delete the session; it merely removes the username and password from the session. If this results in an empty session, - the nett effect will be the removal of that session, but this is not + the net effect will be the removal of that session, but this is not guaranteed. If you want to guarantee the removal of a session, set the <code class="directive"><a href="../mod/mod_session.html#sessionmaxage">SessionMaxAge</a></code> directive to a small - value, like 1. (Setting the directive to zero would mean no session age limit). + value, like 1 (setting the directive to zero would mean no session age limit). </p> <div class="example"><h3>Basic session expiry example</h3><p><code> @@ -527,8 +526,8 @@ lower level modules</td></tr> </code></p></div> <p>An attempt to access the URI <var>/logout/</var> will result in the user being logged - out, and the page <var>/logout.html</var> will be displayed. Make sure that the page - <var>logout.html</var> is not password protected, otherwise the page will not be + out, and the page <var>/loggedout.html</var> will be displayed. Make sure that the page + <var>loggedout.html</var> is not password protected, otherwise the page will not be displayed.</p> diff --git a/docs/manual/mod/mod_auth_form.xml b/docs/manual/mod/mod_auth_form.xml index 09cee85881..64d8d4c7ad 100644 --- a/docs/manual/mod/mod_auth_form.xml +++ b/docs/manual/mod/mod_auth_form.xml @@ -44,16 +44,16 @@ HTML login form can provide a much friendlier experience for end users. </p> - <p>HTTP Basic authentication is provided by - <module>mod_auth_basic</module>, and HTTP Digest Authentication is + <p>HTTP basic authentication is provided by + <module>mod_auth_basic</module>, and HTTP digest authentication is provided by <module>mod_auth_digest</module>. This module should - usually be combined with at least one authentication module + be combined with at least one authentication module such as <module>mod_authn_file</module> and one authorization module such as <module>mod_authz_user</module>.</p> <p>Once the user has been successfully authenticated, the user's login - details will be stored in a suitably configured <strong>session</strong>, - as provided by the <module>mod_session</module> module.</p> + details will be stored in a session provided by <module>mod_session</module>. + </p> </summary> <seealso><module>mod_session</module></seealso> @@ -150,8 +150,8 @@ <p>The URLs specified by the <directive module="mod_auth_form">AuthFormLoginRequiredLocation</directive> directive will typically point to a page explaining to the user that their login attempt was unsuccessful, and they - should try again, while the <directive module="mod_auth_form">AuthFormLoginSuccessLocation</directive> - directive specifies the URL the user should be redirected to on success.</p> + should try again. The <directive module="mod_auth_form">AuthFormLoginSuccessLocation</directive> + directive specifies the URL the user should be redirected to upon successful login.</p> <p>Alternatively, the URL to redirect the user to on success can be embedded within the login form, as in the example below. As a result, the same <var>form-login-handler</var> can be @@ -187,15 +187,15 @@ session is in force, and the session times out in the middle of the user request. The user can be re-authenticated in place, and they can continue where they left off.</p> - <p>When a page protected by <module>mod_auth_form</module> is accessed, and the user is - not logged in, and no <directive module="mod_auth_form">AuthFormLoginRequiredLocation</directive> - directive is specified as described in the section above, an <var>HTTP_UNAUTHORIZED</var> - status code is returned to the browser in the normal way indicating to the user that - they are not authorised to view the page.</p> + <p>If a non-authenticated user attempts to access a page protected by + <module>mod_auth_form</module> that isn't configured with a + <directive module="mod_auth_form">AuthFormLoginRequiredLocation</directive> directive, + a <var>HTTP_UNAUTHORIZED</var> status code is returned to the browser indicating to the user + that they are not authorized to view the page.</p> <p>To configure inline authentication, the administrator overrides the error document - returned by the <var>HTTP_UNAUTHORIZED</var> status code with a custom error document, - containing the login form, as follows.</p> + returned by the <var>HTTP_UNAUTHORIZED</var> status code with a custom error document + containing the login form, as follows:</p> <example><title>Basic inline example</title> AuthFormProvider file<br /> @@ -209,9 +209,8 @@ SessionCryptoPassphrase secret<br /> </example> - <p>The error document file should contain the login form used to log in, as - per the example below. The key difference in this form is that the HTML - form action is left blank. This has the effect of submitting the form to + <p>The error document page should contain a login form with an empty action property, + as per the example below. This has the effect of submitting the form to the original protected URL, without the page having to know what that URL is.</p> @@ -243,7 +242,7 @@ end user.</p> <p><module>mod_auth_form</module> addresses this by allowing the method and body - of the original request to be embedded in the login form, and if authentication + of the original request to be embedded in the login form. If authentication is successful, the original method and body will be retried by Apache, preserving the state of the original request.</p> @@ -269,7 +268,7 @@ <p>One option is to use the <module>mod_include</module> module along with the <directive module="core">KeptBodySize</directive> directive, along with a suitable - CGI script, to embed the variables in the form.</p> + CGI script to embed the variables in the form.</p> <p>Another option is to render the login form using a CGI script or other dynamic technology.</p> @@ -304,12 +303,12 @@ SessionCryptoPassphrase secret<br /> </example> - <p>Note that logging a user out does not delete the session, it merely removes + <p>Note that logging a user out does not delete the session; it merely removes the username and password from the session. If this results in an empty session, - the nett effect will be the removal of that session, but this is not + the net effect will be the removal of that session, but this is not guaranteed. If you want to guarantee the removal of a session, set the <directive module="mod_session">SessionMaxAge</directive> directive to a small - value, like 1. (Setting the directive to zero would mean no session age limit). + value, like 1 (setting the directive to zero would mean no session age limit). </p> <example><title>Basic session expiry example</title> @@ -621,8 +620,8 @@ lower level modules</description> </example> <p>An attempt to access the URI <var>/logout/</var> will result in the user being logged - out, and the page <var>/logout.html</var> will be displayed. Make sure that the page - <var>logout.html</var> is not password protected, otherwise the page will not be + out, and the page <var>/loggedout.html</var> will be displayed. Make sure that the page + <var>loggedout.html</var> is not password protected, otherwise the page will not be displayed.</p> </usage> diff --git a/docs/manual/mod/mod_auth_form.xml.meta b/docs/manual/mod/mod_auth_form.xml.meta index dac885986a..eea8ee2fc6 100644 --- a/docs/manual/mod/mod_auth_form.xml.meta +++ b/docs/manual/mod/mod_auth_form.xml.meta @@ -1,5 +1,4 @@ <?xml version="1.0" encoding="UTF-8" ?> -<!-- GENERATED FROM XML: DO NOT EDIT --> <metafile> <basename>mod_auth_form</basename> diff --git a/docs/manual/mod/mod_session.html.en b/docs/manual/mod/mod_session.html.en index bdd6ad8677..c0aba25280 100644 --- a/docs/manual/mod/mod_session.html.en +++ b/docs/manual/mod/mod_session.html.en @@ -45,11 +45,11 @@ <p>Sessions may be stored on the server, or may be stored on the browser. Sessions may also be optionally encrypted for added security. These features are divided into several modules in addition to - <code class="module"><a href="../mod/mod_session.html">mod_session</a></code>: <code class="module"><a href="../mod/mod_session_crypto.html">mod_session_crypto</a></code>, + <code class="module"><a href="../mod/mod_session.html">mod_session</a></code>; <code class="module"><a href="../mod/mod_session_crypto.html">mod_session_crypto</a></code>, <code class="module"><a href="../mod/mod_session_cookie.html">mod_session_cookie</a></code> and <code class="module"><a href="../mod/mod_session_dbd.html">mod_session_dbd</a></code>. Depending on the server requirements, load the appropriate modules into the server (either statically at compile time or dynamically - via the <code class="directive"><a href="../mod/mod_so.html#loalmodule">LoalModule</a></code> directive).</p> + via the <code class="directive"><a href="../mod/mod_so.html#loadmodule">LoadModule</a></code> directive).</p> <p>Sessions may be manipulated from other modules that depend on the session, or the session may be read from and written to using @@ -87,7 +87,7 @@ <p>At the core of the session interface is a table of key and value pairs that are made accessible across browser requests.</p> - <p>These pairs can be set any valid set of strings, as needed by the + <p>These pairs can be set to any valid string, as needed by the application making use of the session.</p> </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> @@ -330,7 +330,7 @@ <tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Available in Apache 2.3.0 and later</td></tr> </table> <p>The <code class="directive">SessionExclude</code> directive allows sessions to - be disabled specific URL prefixes only. This can be used to make a + be disabled relative to URL prefixes only. This can be used to make a website more efficient, by targeting a more precise URL space for which a session should be maintained. By default, all URLs within the directory or location are included in the session. The diff --git a/docs/manual/mod/mod_session.xml b/docs/manual/mod/mod_session.xml index 0567c2ae63..0848925046 100644 --- a/docs/manual/mod/mod_session.xml +++ b/docs/manual/mod/mod_session.xml @@ -45,11 +45,11 @@ <p>Sessions may be stored on the server, or may be stored on the browser. Sessions may also be optionally encrypted for added security. These features are divided into several modules in addition to - <module>mod_session</module>: <module>mod_session_crypto</module>, + <module>mod_session</module>; <module>mod_session_crypto</module>, <module>mod_session_cookie</module> and <module>mod_session_dbd</module>. Depending on the server requirements, load the appropriate modules into the server (either statically at compile time or dynamically - via the <directive module="mod_so">LoalModule</directive> directive).</p> + via the <directive module="mod_so">LoadModule</directive> directive).</p> <p>Sessions may be manipulated from other modules that depend on the session, or the session may be read from and written to using @@ -64,7 +64,7 @@ <p>At the core of the session interface is a table of key and value pairs that are made accessible across browser requests.</p> - <p>These pairs can be set any valid set of strings, as needed by the + <p>These pairs can be set to any valid string, as needed by the application making use of the session.</p> </section> @@ -392,7 +392,7 @@ <usage> <p>The <directive>SessionExclude</directive> directive allows sessions to - be disabled specific URL prefixes only. This can be used to make a + be disabled relative to URL prefixes only. This can be used to make a website more efficient, by targeting a more precise URL space for which a session should be maintained. By default, all URLs within the directory or location are included in the session. The diff --git a/docs/manual/mod/mod_session.xml.meta b/docs/manual/mod/mod_session.xml.meta index 552c5182ed..8174287b4d 100644 --- a/docs/manual/mod/mod_session.xml.meta +++ b/docs/manual/mod/mod_session.xml.meta @@ -1,5 +1,4 @@ <?xml version="1.0" encoding="UTF-8" ?> -<!-- GENERATED FROM XML: DO NOT EDIT --> <metafile> <basename>mod_session</basename> |