From 33d773ef1b3a220a31f4d4ca882c4360ed3686ea Mon Sep 17 00:00:00 2001 From: "Jason S. Lingohr" Date: Sat, 17 May 2008 06:21:58 +0000 Subject: [PATCH] Minor doc cleanups as submitted by David Shane Holden . Some minor changes by myself from his patch. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@657296 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/mod_auth_form.html.en | 47 +++++++++++++------------- docs/manual/mod/mod_auth_form.xml | 47 +++++++++++++------------- docs/manual/mod/mod_auth_form.xml.meta | 1 - docs/manual/mod/mod_session.html.en | 8 ++--- docs/manual/mod/mod_session.xml | 8 ++--- 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.

-

HTTP Basic authentication is provided by - mod_auth_basic, and HTTP Digest Authentication is +

HTTP basic authentication is provided by + mod_auth_basic, and HTTP digest authentication is provided by mod_auth_digest. This module should - usually be combined with at least one authentication module + be combined with at least one authentication module such as mod_authn_file and one authorization module such as mod_authz_user.

Once the user has been successfully authenticated, the user's login - details will be stored in a suitably configured session, - as provided by the mod_session module.

+ details will be stored in a session provided by mod_session. +

Directives

@@ -179,8 +179,8 @@

The URLs specified by the AuthFormLoginRequiredLocation directive will typically point to a page explaining to the user that their login attempt was unsuccessful, and they - should try again, while the AuthFormLoginSuccessLocation - directive specifies the URL the user should be redirected to on success.

+ should try again. The AuthFormLoginSuccessLocation + directive specifies the URL the user should be redirected to upon successful login.

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 form-login-handler 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.

-

When a page protected by mod_auth_form is accessed, and the user is - not logged in, and no AuthFormLoginRequiredLocation - directive is specified as described in the section above, an HTTP_UNAUTHORIZED - status code is returned to the browser in the normal way indicating to the user that - they are not authorised to view the page.

+

If a non-authenticated user attempts to access a page protected by + mod_auth_form that isn't configured with a + AuthFormLoginRequiredLocation directive, + a HTTP_UNAUTHORIZED status code is returned to the browser indicating to the user + that they are not authorized to view the page.

To configure inline authentication, the administrator overrides the error document - returned by the HTTP_UNAUTHORIZED status code with a custom error document, - containing the login form, as follows.

+ returned by the HTTP_UNAUTHORIZED status code with a custom error document + containing the login form, as follows:

Basic inline example

AuthFormProvider file
@@ -238,9 +238,8 @@ SessionCryptoPassphrase secret

-

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 +

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.

@@ -272,7 +271,7 @@ end user.

mod_auth_form 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.

@@ -298,7 +297,7 @@

One option is to use the mod_include module along with the KeptBodySize directive, along with a suitable - CGI script, to embed the variables in the form.

+ CGI script to embed the variables in the form.

Another option is to render the login form using a CGI script or other dynamic technology.

@@ -333,12 +332,12 @@ SessionCryptoPassphrase secret

-

Note that logging a user out does not delete the session, it merely removes +

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 SessionMaxAge 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).

Basic session expiry example

@@ -527,8 +526,8 @@ lower level modules

An attempt to access the URI /logout/ will result in the user being logged - out, and the page /logout.html will be displayed. Make sure that the page - logout.html is not password protected, otherwise the page will not be + out, and the page /loggedout.html will be displayed. Make sure that the page + loggedout.html is not password protected, otherwise the page will not be displayed.

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.

-

HTTP Basic authentication is provided by - mod_auth_basic, and HTTP Digest Authentication is +

HTTP basic authentication is provided by + mod_auth_basic, and HTTP digest authentication is provided by mod_auth_digest. This module should - usually be combined with at least one authentication module + be combined with at least one authentication module such as mod_authn_file and one authorization module such as mod_authz_user.

Once the user has been successfully authenticated, the user's login - details will be stored in a suitably configured session, - as provided by the mod_session module.

+ details will be stored in a session provided by mod_session. +

mod_session @@ -150,8 +150,8 @@

The URLs specified by the AuthFormLoginRequiredLocation directive will typically point to a page explaining to the user that their login attempt was unsuccessful, and they - should try again, while the AuthFormLoginSuccessLocation - directive specifies the URL the user should be redirected to on success.

+ should try again. The AuthFormLoginSuccessLocation + directive specifies the URL the user should be redirected to upon successful login.

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 form-login-handler 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.

-

When a page protected by mod_auth_form is accessed, and the user is - not logged in, and no AuthFormLoginRequiredLocation - directive is specified as described in the section above, an HTTP_UNAUTHORIZED - status code is returned to the browser in the normal way indicating to the user that - they are not authorised to view the page.

+

If a non-authenticated user attempts to access a page protected by + mod_auth_form that isn't configured with a + AuthFormLoginRequiredLocation directive, + a HTTP_UNAUTHORIZED status code is returned to the browser indicating to the user + that they are not authorized to view the page.

To configure inline authentication, the administrator overrides the error document - returned by the HTTP_UNAUTHORIZED status code with a custom error document, - containing the login form, as follows.

+ returned by the HTTP_UNAUTHORIZED status code with a custom error document + containing the login form, as follows:

Basic inline example AuthFormProvider file
@@ -209,9 +209,8 @@ SessionCryptoPassphrase secret
 -

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 +

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.

@@ -243,7 +242,7 @@ end user.

mod_auth_form 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.

@@ -269,7 +268,7 @@

One option is to use the mod_include module along with the KeptBodySize directive, along with a suitable - CGI script, to embed the variables in the form.

+ CGI script to embed the variables in the form.

Another option is to render the login form using a CGI script or other dynamic technology.

@@ -304,12 +303,12 @@ SessionCryptoPassphrase secret
-

Note that logging a user out does not delete the session, it merely removes +

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 SessionMaxAge 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).

Basic session expiry example @@ -621,8 +620,8 @@ lower level modules

An attempt to access the URI /logout/ will result in the user being logged - out, and the page /logout.html will be displayed. Make sure that the page - logout.html is not password protected, otherwise the page will not be + out, and the page /loggedout.html will be displayed. Make sure that the page + loggedout.html is not password protected, otherwise the page will not be displayed.

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 @@ - mod_auth_form 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 @@

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 - mod_session: mod_session_crypto, + mod_session; mod_session_crypto, mod_session_cookie and mod_session_dbd. Depending on the server requirements, load the appropriate modules into the server (either statically at compile time or dynamically - via the LoalModule directive).

+ via the LoadModule directive).

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 @@

At the core of the session interface is a table of key and value pairs that are made accessible across browser requests.

-

These pairs can be set any valid set of strings, as needed by the +

These pairs can be set to any valid string, as needed by the application making use of the session.

top
@@ -330,7 +330,7 @@ Compatibility:Available in Apache 2.3.0 and later

The SessionExclude 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 @@

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 - mod_session: mod_session_crypto, + mod_session; mod_session_crypto, mod_session_cookie and mod_session_dbd. Depending on the server requirements, load the appropriate modules into the server (either statically at compile time or dynamically - via the LoalModule directive).

+ via the LoadModule directive).

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 @@

At the core of the session interface is a table of key and value pairs that are made accessible across browser requests.

-

These pairs can be set any valid set of strings, as needed by the +

These pairs can be set to any valid string, as needed by the application making use of the session.

@@ -392,7 +392,7 @@

The SessionExclude 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 @@ - mod_session -- 2.40.0