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>
<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
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 />
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>
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>
<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>
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>
</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>
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>
<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
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 />
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>
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>
<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>
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>
</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>
<?xml version="1.0" encoding="UTF-8" ?>
-<!-- GENERATED FROM XML: DO NOT EDIT -->
<metafile>
<basename>mod_auth_form</basename>
<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
<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>
<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
<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
<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>
<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
<?xml version="1.0" encoding="UTF-8" ?>
-<!-- GENERATED FROM XML: DO NOT EDIT -->
<metafile>
<basename>mod_session</basename>
projects / apache / commitdiff