From c466d81a05cb6a2b1c67b56bf2edcf7593e61a8a Mon Sep 17 00:00:00 2001 From: =?utf8?q?Andr=C3=A9=20Malo?= Date: Wed, 16 Oct 2002 06:56:35 +0000 Subject: [PATCH] (re-)add the obsolete module docs. This commit is a base for some discussion and better work on the documents, feel free to add or change the files I stuck with mod_access for now, since there's no decision about yet. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97235 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/obs_mod_access.xml | 325 ++++++++++++++++++++++++ docs/manual/mod/obs_mod_auth.xml | 190 ++++++++++++++ docs/manual/mod/obs_mod_auth_anon.xml | 226 ++++++++++++++++ docs/manual/mod/obs_mod_auth_dbm.xml | 214 ++++++++++++++++ docs/manual/mod/obs_mod_auth_digest.xml | 300 ++++++++++++++++++++++ docs/manual/sitemap.xml | 6 + 6 files changed, 1261 insertions(+) create mode 100644 docs/manual/mod/obs_mod_access.xml create mode 100644 docs/manual/mod/obs_mod_auth.xml create mode 100644 docs/manual/mod/obs_mod_auth_anon.xml create mode 100644 docs/manual/mod/obs_mod_auth_dbm.xml create mode 100644 docs/manual/mod/obs_mod_auth_digest.xml diff --git a/docs/manual/mod/obs_mod_access.xml b/docs/manual/mod/obs_mod_access.xml new file mode 100644 index 0000000000..765f4c7a32 --- /dev/null +++ b/docs/manual/mod/obs_mod_access.xml @@ -0,0 +1,325 @@ + + + + + +mod_access + +Provides access control based on client hostname, IP +address, or other characteristics of the client request. + +Obsolete +replaced by mod_authz_host since 2.0.44 +mod_access.c +access_module +Available only in versions up to 2.0.43 + + + This module is obsolete! +

Note, that this module has been marked as obsolete. A bunch + of modules was introduced in Apache version 2.0.44 that + support the new Authentication/Authorization provider mechnism.

+ +

If you want to use host based access control, you have to invoke the + mod_authz_host module now.

+ +

This document is kept only for historical reasons and no + longer maintained.

+
+ +

The directives provided by mod_access are used in Directory, Files, and Location sections as well as + .htaccess + files to control access to particular parts of the server. Access + can be controlled based on the client hostname, IP address, or + other characteristics of the client request, as captured in environment variables. The Allow and Deny directives are used to + specify which clients are or are not allowed access to the server, + while the Order + directive sets the default access state, and configures how the + Allow and Deny directives interact with each + other.

+ +

Both host-based access restrictions and password-based + authentication may be implemented simultaneously. In that case, + the Satisfy directive is used + to determine how the two sets of restrictions interact.

+ +

In general, access restriction directives apply to all + access methods (GET, PUT, + POST, etc). This is the desired behavior in most + cases. However, it is possible to restrict some methods, while + leaving other methods unrestricted, by enclosing the directives + in a Limit section.

+
+ +Satisfy +Require + + +Allow + +Controls which hosts can access an area of the +server + Allow from + all|host|env=env-variable + [host|env=env-variable] ... +directory.htaccess + +Limit + + + +

The Allow directive affects which hosts can + access an area of the server. Access can be controlled by + hostname, IP Address, IP Address range, or by other + characteristics of the client request captured in environment + variables.

+ +

The first argument to this directive is always + from. The subsequent arguments can take three + different forms. If Allow from all is specified, then + all hosts are allowed access, subject to the configuration of the + Deny and Order directives as discussed + below. To allow only particular hosts or groups of hosts to access + the server, the host can be specified in any of the + following formats:

+ +
+
A (partial) domain-name
+ +
Example: Allow from apache.org
+ Hosts whose names match, or end in, this string are allowed + access. Only complete components are matched, so the above + example will match foo.apache.org but it will + not match fooapache.org. This configuration will + cause the server to perform a reverse DNS lookup on the + client IP address, regardless of the setting of the HostnameLookups + directive.
+ +
A full IP address
+ +
Example: Allow from 10.1.2.3
+ An IP address of a host allowed access
+ +
A partial IP address
+ +
Example: Allow from 10.1
+ The first 1 to 3 bytes of an IP address, for subnet + restriction.
+ +
A network/netmask pair
+ +
Example: Allow from + 10.1.0.0/255.255.0.0
+ A network a.b.c.d, and a netmask w.x.y.z. For more + fine-grained subnet restriction.
+ +
A network/nnn CIDR specification
+ +
Example: Allow from 10.1.0.0/16
+ Similar to the previous case, except the netmask consists of + nnn high-order 1 bits.
+
+ +

Note that the last three examples above match exactly the + same set of hosts.

+ +

IPv6 addresses and IPv6 subnets can be specified as shown + below:

+ + + Allow from fe80::a00:20ff:fea7:ccea
+ Allow from fe80::a00:20ff:fea7:ccea/10 +
+ +

The third format of the arguments to the + Allow directive allows access to the server + to be controlled based on the existence of an environment variable. When Allow from + env=env-variable is specified, then the request is + allowed access if the environment variable env-variable + exists. The server provides the ability to set environment + variables in a flexible way based on characteristics of the client + request using the directives provided by + mod_setenvif. Therefore, this directive can be + used to allow access based on such factors as the clients + User-Agent (browser type), Referer, or + other HTTP request header fields.

+ + Example: + SetEnvIf User-Agent ^KnockKnock/2.0 let_me_in
+ <Directory /docroot>
+ + Order Deny,Allow
+ Deny from all
+ Allow from env=let_me_in
+
+ </Directory> +
+ +

In this case, browsers with a user-agent string beginning + with KnockKnock/2.0 will be allowed access, and all + others will be denied.

+
+ +
+ + + +Deny + +Controls which hosts are denied access to the +server + + Deny from + all|host|env=env-variable + [host|env=env-variable] ... +directory.htaccess + +Limit + + +

This directive allows access to the server to be restricted + based on hostname, IP address, or environment variables. The + arguments for the Deny directive are + identical to the arguments for the Allow directive.

+
+ +
+ + + +Order + +Controls the default access state and the order in which +Allow and Deny are +evaluated. + + Order ordering +Order Deny,Allow +directory.htaccess + +Limit + + + +

The Order directive controls the default + access state and the order in which Allow and Deny directives are evaluated. + Ordering is one of

+ +
+
Deny,Allow
+ +
The Deny directives + are evaluated before the Allow directives. Access is + allowed by default. Any client which does not match a + Deny directive or does + match an Allow + directive will be allowed access to the server.
+ +
Allow,Deny
+ +
The Allow + directives are evaluated before the Deny directives. Access is denied + by default. Any client which does not match an Allow directive or does match a + Deny directive will be + denied access to the server.
+ +
Mutual-failure
+ +
Only those hosts which appear on the Allow list and do not appear on + the Deny list are + granted access. This ordering has the same effect as Order + Allow,Deny and is deprecated in favor of that + configuration.
+
+ +

Keywords may only be separated by a comma; no whitespace is + allowed between them. Note that in all cases every Allow and Deny statement is evaluated.

+ +

In the following example, all hosts in the apache.org domain + are allowed access; all other hosts are denied access.

+ + + Order Deny,Allow
+ Deny from all
+ Allow from apache.org +
+ +

In the next example, all hosts in the apache.org domain are + allowed access, except for the hosts which are in the + foo.apache.org subdomain, who are denied access. All hosts not + in the apache.org domain are denied access because the default + state is to deny access to the server.

+ + + Order Allow,Deny
+ Allow from apache.org
+ Deny from foo.apache.org +
+ +

On the other hand, if the Order in the last + example is changed to Deny,Allow, all hosts will + be allowed access. This happens because, regardless of the + actual ordering of the directives in the configuration file, + the Allow from apache.org will be evaluated last + and will override the Deny from foo.apache.org. + All hosts not in the apache.org domain will also + be allowed access because the default state will change to + allow.

+ +

The presence of an Order directive can affect + access to a part of the server even in the absence of accompanying + Allow and Deny directives because of its effect + on the default access state. For example,

+ + + <Directory /www>
+ + Order Allow,Deny
+
+ </Directory> +
+ +

will deny all access to the /www directory + because the default access state will be set to + deny.

+ +

The Order directive controls the order of access + directive processing only within each phase of the server's + configuration processing. This implies, for example, that an + Allow or Deny directive occurring in a + Location section will + always be evaluated after an Allow or Deny directive occurring in a + Directory section or + .htaccess file, regardless of the setting of the + Order directive. For details on the merging + of configuration sections, see the documentation on How Directory, Location and Files sections + work.

+
+ +
+ +
diff --git a/docs/manual/mod/obs_mod_auth.xml b/docs/manual/mod/obs_mod_auth.xml new file mode 100644 index 0000000000..9085ccf7d6 --- /dev/null +++ b/docs/manual/mod/obs_mod_auth.xml @@ -0,0 +1,190 @@ + + + + + +mod_auth +User authentication using text files +Obsolete +obsolete since 2.0.44 +mod_auth.c +auth_module +Available only in versions up to 2.0.43 + + + This module is obsolete! +

Note, that this module has been marked as obsolete. A bunch + of modules was introduced in Apache version 2.0.44 that + support the new Authentication/Authorization provider mechnism.

+ +

In order to get the ability of HTTP Basic Authentication, you have + to use the mod_auth_basic module that implements + the HTTP part. mod_authn_file provides for user + authentication based on plain text files. File based group + authorization is now done by the mod_authz_groupfile + module.

+ +

This document is kept only for historical reasons and no + longer maintained.

+
+ +

This module allows the use of HTTP Basic Authentication to + restrict access by looking up users in plain text password and + group files. Similar functionality and greater scalability is + provided by mod_auth_dbm. HTTP Digest + Authentication is provided by + mod_auth_digest.

+ +
+Require +Satisfy +AuthName +AuthType + + +AuthGroupFile +Sets the name of a text file containing the list +of user groups for authentication +AuthGroupFile file-path +directory.htaccess + +AuthConfig + + +

The AuthGroupFile directive sets the + name of a textual file containing the list of user groups for user + authentication. File-path is the path to the group + file. If it is not absolute (i.e., if it doesn't begin + with a slash), it is treated as relative to the ServerRoot.

+ +

Each line of the group file contains a groupname followed by a + colon, followed by the member usernames separated by spaces. + Example:

+ + mygroup: bob joe anne + +

Note that searching large text files is very + inefficient; AuthDBMGroupFile should be used + instead.

+ + Security +

Make sure that the AuthGroupFile is + stored outside the document tree of the web-server; do not + put it in the directory that it protects. Otherwise, clients will + be able to download the AuthGroupFile.

+
+
+
+ + +AuthUserFile +Sets the name of a text file containing the list of users and +passwords for authentication +AuthUserFile file-path +directory.htaccess + +AuthConfig + + +

The AuthUserFile directive sets the name + of a textual file containing the list of users and passwords for + user authentication. File-path is the path to the user + file. If it is not absolute (i.e., if it doesn't begin + with a slash), it is treated as relative to the ServerRoot.

+ +

Each line of the user file contains a username followed by + a colon, followed by the crypt() encrypted + password. The behavior of multiple occurrences of the same user is + undefined.

+ +

The utility htpasswd + which is installed as part of the binary distribution, or which + can be found in src/support, is used to maintain + this password file. See the man page for more + details. In short:

+ +

Create a password file 'Filename' with 'username' as the + initial ID. It will prompt for the password:

+ + htpasswd -c Filename username + +

Add or modify 'username2' in the password file 'Filename':

+ + htpasswd Filename username2 + +

Note that searching large text files is very + inefficient; AuthDBMUserFile should be used + instead.

+ + Security +

Make sure that the AuthUserFile is + stored outside the document tree of the web-server; do not + put it in the directory that it protects. Otherwise, clients will + be able to download the AuthUserFile.

+
+
+
+ + +AuthAuthoritative +Sets whether authorization and authentication are +passed to lower level modules +AuthAuthoritative on|off +AuthAuthoritative on +directory.htaccess + +AuthConfig + + + This information has not been updated for Apache 2.0, which + uses a different system for module ordering. + +

Setting the AuthAuthoritative directive + explicitly to 'off' allows for both + authentication and authorization to be passed on to lower level + modules (as defined in the Configuration and + modules.c files) if there is no + userID or rule matching the supplied + userID. If there is a userID and/or rule specified; the usual + password and access checks will be applied and a failure will give + an Authorization Required reply.

+ +

So if a userID appears in the database of more than one module; + or if a valid Require + directive applies to more than one module; then the first module + will verify the credentials; and no access is passed on; + regardless of the AuthAuthoritative setting.

+ +

A common use for this is in conjunction with one of the + database modules; such as mod_auth_dbm, + mod_auth_msql, and mod_auth_anon. + These modules supply the bulk of the user credential checking; but + a few (administrator) related accesses fall through to a lower + level with a well protected AuthUserFile.

+ +

By default; control is not passed on; and an unknown userID or + rule will result in an Authorization Required reply. Not setting + it thus keeps the system secure; and forces an NCSA compliant + behaviour.

+ + Security Do consider the implications of + allowing a user to allow fall-through in his .htaccess file; and + verify that this is really what you want; Generally it is easier + to just secure a single .htpasswd file, than it is to secure a + database such as mSQL. Make sure that the AuthUserFile and the AuthGroupFile are stored outside the + document tree of the web-server; do not put them in the + directory that they protect. Otherwise, clients will be able to + download the AuthUserFile + and the AuthGroupFile. + +
+
+ +
diff --git a/docs/manual/mod/obs_mod_auth_anon.xml b/docs/manual/mod/obs_mod_auth_anon.xml new file mode 100644 index 0000000000..8689f9628a --- /dev/null +++ b/docs/manual/mod/obs_mod_auth_anon.xml @@ -0,0 +1,226 @@ + + + + + +mod_auth_anon +Allows "anonymous" user access to authenticated + areas +Obsolete +replaced by mod_authn_anon since 2.0.44 +mod_auth_anon.c +auth_anon_module +Available only in versions up to 2.0.43 + + + This module is obsolete! +

Note, that this module has been marked as obsolete. A bunch + of modules was introduced in Apache version 2.0.44 that + support the new Authentication/Authorization provider mechnism.

+ +

In order to get the same functionality, you have to invoke the + mod_authn_anon module now.

+ + + + +

This document is kept only for historical reasons and no + longer maintained.

+
+ +

This module does access control in a manner similar to + anonymous-ftp sites; i.e. have a 'magic' user id + 'anonymous' and the email address as a password. These email + addresses can be logged.

+ +

Combined with other (database) access control methods, this + allows for effective user tracking and customization according + to a user profile while still keeping the site open for + 'unregistered' users. One advantage of using Auth-based user + tracking is that, unlike magic-cookies and funny URL + pre/postfixes, it is completely browser independent and it + allows users to share URLs.

+
+ +
Example + +

The example below (when combined with the Auth directives of a + htpasswd-file based (or GDM, mSQL etc.) base access + control system allows users in as 'guests' with the following + properties:

+ +
    +
  • It insists that the user enters a userId. + (Anonymous_NoUserId)
  • + +
  • It insists that the user enters a password. + (Anonymous_MustGiveEmail)
  • + +
  • The password entered must be a valid email address, ie. + contain at least one '@' and a '.'. + (Anonymous_VerifyEmail)
  • + +
  • The userID must be one of anonymous guest www test + welcome and comparison is not case + sensitive.
  • + +
  • And the Email addresses entered in the passwd field are + logged to the error log file + (Anonymous_LogEmail)
  • +
+ +

Excerpt of httpd.conf:

+ + + Anonymous_NoUserId off
+ Anonymous_MustGiveEmail on
+ Anonymous_VerifyEmail on
+ Anonymous_LogEmail on
+ Anonymous anonymous guest www test welcome
+
+ AuthName "Use 'anonymous' & Email address for guest entry"
+ AuthType basic
+
+ # An + AuthUserFile/AuthDBUserFile/AuthDBMUserFile
+ # directive must be specified, or use
+ # Anonymous_Authoritative for public access.
+ # In the .htaccess for the public directory, add:
+ <Files *>
+ + Order Deny,Allow
+ Allow from all
+
+ Require valid-user
+
+ </Files> +
+
+ + +Anonymous +Specifies userIDs that areallowed access without +password verification +Anonymous user [user] ... +directory.htaccess + +AuthConfig + + +

A list of one or more 'magic' userIDs which are allowed + access without password verification. The userIDs are space + separated. It is possible to use the ' and " quotes to allow a + space in a userID as well as the \ escape character.

+ +

Please note that the comparison is + case-IN-sensitive.
+ I strongly suggest that the magic username + 'anonymous' is always one of the allowed + userIDs.

+ + Example: + Anonymous anonymous "Not Registered" 'I don\'t know' + + +

This would allow the user to enter without password + verification by using the userId's 'anonymous', + 'AnonyMous','Not Registered' and 'I Don't Know'.

+
+
+ + +Anonymous_Authoritative +Configures if authorization will fall-through +to other methods +Anonymous_Authoritative on|off +Anonymous_Authoritative off +directory.htaccess + +AuthConfig + + +

When set 'on', there is no fall-through to other authorization + methods. So if a userID does not match the values specified in the + Anonymous directive, + access is denied.

+ +

Be sure you know what you are doing when you decide to + switch it on. And remember that it is the linking order of the + modules (in the Configuration / Make file) which details the + order in which the Authorization modules are queried.

+
+
+ + +Anonymous_LogEmail +Sets whether the password entered will be logged in the +error log +Anonymous_LogEmail on|off +Anonymous_LogEmail on +directory.htaccess + +AuthConfig + + +

When set on, the default, the 'password' entered + (which hopefully contains a sensible email address) is logged in + the error log.

+
+
+ + +Anonymous_MustGiveEmail +Specifies whether blank passwords are allowed +Anonymous_MustGiveEmail on|off +Anonymous_MustGiveEmail on +directory.htaccess + +AuthConfig + + +

Specifies whether the user must specify an email address as + the password. This prohibits blank passwords.

+
+
+ + +Anonymous_NoUserID +Sets whether the userID field may be empty +Anonymous_NoUserID on|off +Anonymous_NoUserID off +directory.htaccess + +AuthConfig + + +

When set on, users can leave the userID (and + perhaps the password field) empty. This can be very convenient for + MS-Explorer users who can just hit return or click directly on the + OK button; which seems a natural reaction.

+
+
+ + +Anonymous_VerifyEmail +Sets whether to check the password field for a correctly +formatted email address +Anonymous_VerifyEmail on|off +Anonymous_VerifyEmail off +directory.htaccess + +AuthConfig + + +

When set on the 'password' entered is checked for + at least one '@' and a '.' to encourage users to enter valid email + addresses (see the above Auth_LogEmail).

+
+
+ +
\ No newline at end of file diff --git a/docs/manual/mod/obs_mod_auth_dbm.xml b/docs/manual/mod/obs_mod_auth_dbm.xml new file mode 100644 index 0000000000..6f0703bd6a --- /dev/null +++ b/docs/manual/mod/obs_mod_auth_dbm.xml @@ -0,0 +1,214 @@ + + + + + +mod_auth_dbm +Provides for user authentication using DBM + files +Obsolete +obsolete since 2.0.44 +mod_auth_dbm.c +auth_dbm_module +Available only in versions up to 2.0.43 + + + This module is obsolete! +

Note, that this module has been marked as obsolete. A bunch + of modules was introduced in Apache version 2.0.44 that + support the new Authentication/Authorization provider mechnism.

+ +

In order to get the ability of HTTP Basic Authentication, you have + to use the mod_auth_basic module that implements + the HTTP part. mod_authn_dbm provides for user + authentication based on DBM-files. DBM-File based group + authorization is now done by the mod_authz_dbm + module.

+ +

This document is kept only for historical reasons and no + longer maintained.

+
+ +

This module provides for HTTP Basic Authentication, where + the usernames and passwords are stored in DBM type database + files. It is an alternative to the plain text password files + provided by mod_auth.

+
+ +AuthName +AuthType +Require +Satisfy + + +AuthDBMGroupFile +Sets the name of the database file containing the list +of user groups for authentication +AuthDBMGroupFile file-path +directory.htaccess + +AuthConfig + + +

The AuthDBMGroupFile directive sets the + name of a DBM file containing the list of user groups for user + authentication. File-path is the absolute path to the + group file.

+ +

The group file is keyed on the username. The value for a + user is a comma-separated list of the groups to which the users + belongs. There must be no whitespace within the value, and it + must never contain any colons.

+ +

Security: make sure that the + AuthDBMGroupFile is stored outside the + document tree of the web-server; do not put it in the + directory that it protects. Otherwise, clients will be able to + download the AuthDBMGroupFile unless + otherwise protected.

+ +

Combining Group and Password DBM files: In some cases it is + easier to manage a single database which contains both the + password and group details for each user. This simplifies any + support programs that need to be written: they now only have to + deal with writing to and locking a single DBM file. This can be + accomplished by first setting the group and password files to + point to the same DBM:

+ + + AuthDBMGroupFile /www/userbase
+ AuthDBMUserFile /www/userbase +
+ +

The key for the single DBM is the username. The value consists + of

+ + + Unix Crypt-ed Password:List of Groups[:(ignored)] + + +

The password section contains the Unix crypt() + password as before. This is followed by a colon and the comma + separated list of groups. Other data may optionally be left in the + DBM file after another colon; it is ignored by the authentication + module. This is what www.telescope.org uses for its combined + password and group database.

+
+
+ + +AuthDBMUserFile +Sets thename of a database file containing the list of users and +passwords for authentication +AuthDBMUserFile file-path +directory.htaccess + +AuthConfig + + +

The AuthDBMUserFile directive sets the + name of a DBM file containing the list of users and passwords for + user authentication. File-path is the absolute path to + the user file.

+ +

The user file is keyed on the username. The value for a user is + the crypt() encrypted password, optionally followed + by a colon and arbitrary data. The colon and the data following it + will be ignored by the server.

+ +

Security: make sure that the + AuthDBMUserFile is stored outside the + document tree of the web-server; do not put it in the + directory that it protects. Otherwise, clients will be able to + download the AuthDBMUserFile.

+ +

Important compatibility note: The implementation of + "dbmopen" in the apache modules reads the string length of the + hashed values from the DBM data structures, rather than relying + upon the string being NULL-appended. Some applications, such as + the Netscape web server, rely upon the string being + NULL-appended, so if you are having trouble using DBM files + interchangeably between applications this may be a part of the + problem.

+ +

A perl script called + dbmmanage is included with + Apache. This program can be used to create and update DBM + format password files for use with this module.

+
+
+ + +AuthDBMType +Sets the type of database file that is used to +store passwords +AuthDBMType default|SDBM|GDBM|NDBM|DB +AuthDBMType default +directory.htaccess + +AuthConfig +Available in version 2.0.30 and later. + + + +

Sets the type of database file that is used to store the passwords. +The default database type is determined at compile time. The +availability of other types of database files also depends on +compile-time settings.

+ +

It is crucial that whatever program you use to create your password +files is configured to use the same type of database.

+
+
+ + +AuthDBMAuthoritative +Sets whether authentication and authorization will be +passwed on to lower level modules +AuthDBMAuthoritative on|off +AuthDBMAuthoritative on +directory.htaccess + +AuthConfig + + + +This information has not been updated to take into account the +new module ordering techniques in Apache 2.0 + +

Setting the AuthDBMAuthoritative + directive explicitly to 'off' allows for both + authentication and authorization to be passed on to lower level + modules (as defined in the Configuration and + modules.c file if there is no userID + or rule matching the supplied userID. If there is + a userID and/or rule specified; the usual password and access + checks will be applied and a failure will give an Authorization + Required reply.

+ +

So if a userID appears in the database of more than one module; + or if a valid Require + directive applies to more than one module; then the first module + will verify the credentials; and no access is passed on; + regardless of the AuthAuthoritative setting.

+ +

A common use for this is in conjunction with one of the + basic auth modules; such as mod_auth. Whereas this + DBM module supplies the bulk of the user credential checking; a + few (administrator) related accesses fall through to a lower + level with a well protected .htpasswd file.

+ +

By default, control is not passed on and an unknown userID + or rule will result in an Authorization Required reply. Not + setting it thus keeps the system secure and forces an NCSA + compliant behaviour.

+ +

Security: Do consider the implications of allowing a user to + allow fall-through in his .htaccess file; and verify that this + is really what you want; Generally it is easier to just secure + a single .htpasswd file, than it is to secure a database which + might have more access interfaces.

+
+
+ +
\ No newline at end of file diff --git a/docs/manual/mod/obs_mod_auth_digest.xml b/docs/manual/mod/obs_mod_auth_digest.xml new file mode 100644 index 0000000000..ad4b82ef77 --- /dev/null +++ b/docs/manual/mod/obs_mod_auth_digest.xml @@ -0,0 +1,300 @@ + + + + +mod_auth_digest +User authentication using MD5 + Digest Authentication. +Obsolete +obsolete since 2.0.44 +mod_auth_digest.c +auth_digest_module +Available only in versions up to 2.0.43. The new module +that unfortunately is also named mod_auth_digest +includes support for the auth provider mechanism introduced +in 2.0.44. + + + This module is obsolete! +

Note, that this module has been marked as obsolete. A bunch + of modules was introduced in Apache version 2.0.44 that + support the new Authentication/Authorization provider mechnism.

+ +

In order to get the ability of HTTP Digest Authentication, you have + to use the new mod_auth_digest module that implements + the HTTP part. The user and group data management is provided by the + mod_authn_* and mod_authz_* modules. If you + want to use your existing user files, have a look at mod_authn_file.

+ +

This document is kept only for historical reasons and no + longer maintained.

+
+ +

This module implements HTTP Digest Authentication. However, it + has not been extensively tested and is therefore marked + experimental.

+
+ +AuthName +AuthType +Require +Satisfy + +
Using Digest Authentication + +

Using MD5 Digest authentication is very simple. Simply set + up authentication normally, using "AuthType Digest" and + "AuthDigestFile" instead of the normal "AuthType Basic" and + "AuthUserFile"; also, replace any "AuthGroupFile" with + "AuthDigestGroupFile". Then add a "AuthDigestDomain" directive + containing at least the root URI(s) for this protection space. + Example:

+ + + <Location /private/>
+ + AuthType Digest
+ AuthName "private area"
+ AuthDigestDomain /private/ http://mirror.my.dom/private2/
+ AuthDigestFile /web/auth/.digest_pw
+ Require valid-user
+
+ </Location> +
+ + Note +

Digest authentication provides a more secure password system + than Basic authentication, but only works with supporting + browsers. As of July 2002, the major browsers that support digest + authentication are Opera, MS Internet + Explorer (fails when used with a query string), Amaya and Mozilla. Since digest + authentication is not as widely implemented as basic + authentication, you should use it only in controlled settings.

+
+
+ + +AuthDigestFile +Location of the text file containing the list +of users and encoded passwords for digest authentication +AuthDigestFile file-path +directory.htaccess + +AuthConfig + + +

The AuthDigestFile directive sets the + name of a textual file containing the list of users and encoded + passwords for digest authentication. File-path is the + absolute path to the user file.

+ +

The digest file uses a special format. Files in this format + can be created using the htdigest utility found in + the support/ subdirectory of the Apache distribution.

+
+
+ + +AuthDigestGroupFile +Name of the text file containing the list of groups +for digest authentication +AuthDigestGroupFile file-path +directory.htaccess + +AuthConfig + + +

The AuthDigestGroupFile directive sets + the name of a textual file containing the list of groups and their + members (user names). File-path is the absolute path to + the group file.

+ +

Each line of the group file contains a groupname followed by + a colon, followed by the member usernames separated by spaces. + Example:

+ + mygroup: bob joe anne + +

Note that searching large text files is very + inefficient.

+ +

Security: make sure that the AuthGroupFile is stored outside + the document tree of the web-server; do not put it in + the directory that it protects. Otherwise, clients will be able + to download the AuthGroupFile.

+
+
+ + +AuthDigestQop +Determines the quality-of-protection to use in digest +authentication +AuthDigestQop none|auth|auth-int [auth|auth-int] +AuthDigestQop auth +directory.htaccess + +AuthConfig + + +

The AuthDigestQop directive determines + the quality-of-protection to use. auth will only do + authentication (username/password); auth-int is + authentication plus integrity checking (an MD5 hash of the entity + is also computed and checked); none will cause the module + to use the old RFC-2069 digest algorithm (which does not include + integrity checking). Both auth and auth-int may + be specified, in which the case the browser will choose which of + these to use. none should only be used if the browser for + some reason does not like the challenge it receives otherwise.

+ + + auth-int is not implemented yet. + +
+
+ + +AuthDigestNonceLifetime +How long the server nonce is valid +AuthDigestNonceLifetime seconds +AuthDigestNonceLifetime 300 +directory.htaccess + +AuthConfig + + +

The AuthDigestNonceLifetime directive + controls how long the server nonce is valid. When the client + contacts the server using an expired nonce the server will send + back a 401 with stale=true. If seconds is + greater than 0 then it specifies the amount of time for which the + nonce is valid; this should probably never be set to less than 10 + seconds. If seconds is less than 0 then the nonce never + expires. +

+
+
+ + +AuthDigestNonceFormat +Determines how the nonce is generated +AuthDigestNonceFormat format +directory.htaccess + +AuthConfig + + +

Not implemented yet. +

+
+
+ + +AuthDigestNcCheck +Enables or disables checking of the nonce-count sent by the +server +AuthDigestNcCheck On|Off +AuthDigestNcCheck Off +server config + + + + Not implemented yet. + + + + + + +AuthDigestAlgorithm +Selects the algorithm used to calculate the challenge and +response hases in digest authentication +AuthDigestAlgorithm MD5|MD5-sess +AuthDigestAlgorithm MD5 +directory.htaccess + +AuthConfig + + +

The AuthDigestAlgorithm directive + selects the algorithm used to calculate the challenge and response + hashes.

+ + + MD5-sess is not correctly implemented yet. + + +
+
+ + +AuthDigestDomain +URIs that are in the same protection space for digest +authentication +AuthDigestDomain URI [URI] ... +directory.htaccess + +AuthConfig + + +

The AuthDigestDomain directive allows + you to specify one or more URIs which are in the same protection + space (i.e. use the same realm and username/password info). The + specified URIs are prefixes, i.e. the client will assume that all + URIs "below" these are also protected by the same + username/password. The URIs may be either absolute URIs + (i.e. inluding a scheme, host, port, etc) or relative URIs.

+ +

This directive should always be specified and + contain at least the (set of) root URI(s) for this space. + Omitting to do so will cause the client to send the + Authorization header for every request sent to this + server. Apart from increasing the size of the request, it may + also have a detrimental effect on performance if + "AuthDigestNcCheck" is on.

+ +

The URIs specified can also point to different servers, in + which case clients (which understand this) will then share + username/password info across multiple servers without + prompting the user each time.

+
+
+ +
+ + + diff --git a/docs/manual/sitemap.xml b/docs/manual/sitemap.xml index ce4243b4ad..29d6519196 100644 --- a/docs/manual/sitemap.xml +++ b/docs/manual/sitemap.xml @@ -181,6 +181,12 @@ Server on HPUX perchild.xml prefork.xml worker.xml + + obs_mod_access.xml + obs_mod_auth.xml + obs_mod_auth_anon.xml + obs_mod_auth_dbm.xml + obs_mod_auth_digest.xml -- 2.40.0