docs/manual/mod/mod_auth_dbm.html - httpd - Git at Google

 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
 <HTML>
 <HEAD>
 <TITLE>Apache module mod_auth_dbm</TITLE>
 </HEAD>

 <BODY>
 <!--#include virtual="header.html" -->

 <H1>Module mod_auth_dbm</h1>

 This module is contained in the <code>mod_auth_dbm.c</code> file, and
 is not compiled in by default. It provides for user authentication using
 DBM files.


 <menu>
 <li><A HREF="#authdbmgroupfile">AuthDBMGroupFile</A>
 <li><A HREF="#authdbmuserfile">AuthDBMUserFile</A>
 <li><A HREF="#authdbmauthoritative">AuthDBMAuthoritative</A>
 </menu>
 <hr>


 <A name="authdbmgroupfile"><h2>AuthDbmGroupFile</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthDbmGroupFile} directive&gt; -->
 <strong>Syntax:</strong> AuthDBMGroupFile <em>filename</em><br>
 <Strong>Context:</strong> directory, .htaccess<br>
 <Strong>Override:</strong> AuthConfig<br>
 <strong>Status:</strong> Extension<br>
 <strong>Module:</strong> mod_auth_dbm<p>

 The AuthDBMGroupFile directive sets the name of a DBM file containing the list
 of user groups for user authentication. <em>Filename</em> is the absolute path
 to the group file.<p>

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

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

 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:<p>

 <blockquote><code>
 AuthDBMGroupFile /www/userbase<br>
 AuthDBMUserFile /www/userbase
 </code></blockquote>

 The key for the single DBM is the username. The value consists of <p>

 <blockquote><code>
 Unix Crypt-ed Password : List of Groups [ : (ignored) ]
 </code></blockquote>

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

 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
 <A HREF="#authdbmuserfile">AuthDBMUserFile</A>.<p><hr>

 <A name="authdbmuserfile"><h2>AuthDBMUserFile</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthDBMUserFile} directive&gt; -->
 <strong>Syntax:</strong> AuthDBMUserFile <em>filename</em><br>
 <Strong>Context:</strong> directory, .htaccess<br>
 <Strong>Override:</strong> AuthConfig<br>
 <strong>Status:</strong> Extension<br>
 <strong>Module:</strong> mod_auth_dbm<p>

 The AuthDBMUserFile directive sets the name of a DBM file containing the list
 of users and passwords for user authentication. <em>Filename</em> is the
 absolute path to the user file.<p>

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

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

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

 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
 <A HREF="#authdbmgroupfile">AuthDBMGroupFile</A>.<p>

 <hr>
 <A name="authdbmauthoritative"><h2>AuthDBMAuthoritative</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthDBMAuthoritative} directive&gt; -->
 <strong>Syntax:</strong> AuthDBMAuthoritative &lt; <strong> on</strong>(default) | off &gt; <br>
 <Strong>Context:</strong> directory, .htaccess<br>
 <Strong>Override:</strong> AuthConfig<br>
 <strong>Status:</strong> Base<br>
 <strong>Module:</strong> mod_auth<p>

 Setting the AuthDBMAuthoritative directive explicitly to <b>'off'</b> allows for both authentification and authorization to be passed on to lower level modules (as defined in the <code>Configuration</code> and <code>modules.c</code> file if there is <b>no userID</b> or <b>rule</b> 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.
 <p>
 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.
 <p>
 A common use for this is in conjection with one of the basic auth modules; such
 as <a href="mod_auth.html"><code>mod_auth.c</code></a>. 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.
 <p>
 <b>Default:</b> By default; control is not passed on; and an unkown userID or rule will result in an Authorization Required reply. Not setting it thus keeps the system secure; and forces an NSCA compliant behaviour.
 <p>
 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.

 <p>
 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
 <A HREF="#authgroupfile">AuthGroupFile</A>.<p>

 <!--#include virtual="footer.html" -->
 </BODY>
 </HTML>
	<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
	<HTML>
	<HEAD>
	<TITLE>Apache module mod_auth_dbm</TITLE>
	</HEAD>

	<BODY>
	<!--#include virtual="header.html" -->

	<H1>Module mod_auth_dbm</h1>

	This module is contained in the <code>mod_auth_dbm.c</code> file, and
	is not compiled in by default. It provides for user authentication using
	DBM files.


	<menu>
	<li><A HREF="#authdbmgroupfile">AuthDBMGroupFile</A>
	<li><A HREF="#authdbmuserfile">AuthDBMUserFile</A>
	<li><A HREF="#authdbmauthoritative">AuthDBMAuthoritative</A>
	</menu>
	<hr>


	<A name="authdbmgroupfile"><h2>AuthDbmGroupFile</h2></A>
	<!--%plaintext <?INDEX {\tt AuthDbmGroupFile} directive> -->
	<strong>Syntax:</strong> AuthDBMGroupFile <em>filename</em><br>
	<Strong>Context:</strong> directory, .htaccess<br>
	<Strong>Override:</strong> AuthConfig<br>
	<strong>Status:</strong> Extension<br>
	<strong>Module:</strong> mod_auth_dbm<p>

	The AuthDBMGroupFile directive sets the name of a DBM file containing the list
	of user groups for user authentication. <em>Filename</em> is the absolute path
	to the group file.<p>

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

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

	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:<p>

	<blockquote><code>
	AuthDBMGroupFile /www/userbase<br>
	AuthDBMUserFile /www/userbase
	</code></blockquote>

	The key for the single DBM is the username. The value consists of <p>

	<blockquote><code>
	Unix Crypt-ed Password : List of Groups [ : (ignored) ]
	</code></blockquote>

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

	See also <A HREF="core.html#authname">AuthName</A>,
	<A HREF="core.html#authtype">AuthType</A> and
	<A HREF="#authdbmuserfile">AuthDBMUserFile</A>.<p><hr>

	<A name="authdbmuserfile"><h2>AuthDBMUserFile</h2></A>
	<!--%plaintext <?INDEX {\tt AuthDBMUserFile} directive> -->
	<strong>Syntax:</strong> AuthDBMUserFile <em>filename</em><br>
	<Strong>Context:</strong> directory, .htaccess<br>
	<Strong>Override:</strong> AuthConfig<br>
	<strong>Status:</strong> Extension<br>
	<strong>Module:</strong> mod_auth_dbm<p>

	The AuthDBMUserFile directive sets the name of a DBM file containing the list
	of users and passwords for user authentication. <em>Filename</em> is the
	absolute path to the user file.<p>

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

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

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

	See also <A HREF="core.html#authname">AuthName</A>,
	<A HREF="core.html#authtype">AuthType</A> and
	<A HREF="#authdbmgroupfile">AuthDBMGroupFile</A>.<p>

	<hr>
	<A name="authdbmauthoritative"><h2>AuthDBMAuthoritative</h2></A>
	<!--%plaintext <?INDEX {\tt AuthDBMAuthoritative} directive> -->
	<strong>Syntax:</strong> AuthDBMAuthoritative < <strong> on</strong>(default) \| off > <br>
	<Strong>Context:</strong> directory, .htaccess<br>
	<Strong>Override:</strong> AuthConfig<br>
	<strong>Status:</strong> Base<br>
	<strong>Module:</strong> mod_auth<p>

	Setting the AuthDBMAuthoritative directive explicitly to <b>'off'</b> allows for both authentification and authorization to be passed on to lower level modules (as defined in the <code>Configuration</code> and <code>modules.c</code> file if there is <b>no userID</b> or <b>rule</b> 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.
	<p>
	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.
	<p>
	A common use for this is in conjection with one of the basic auth modules; such
	as <a href="mod_auth.html"><code>mod_auth.c</code></a>. 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.
	<p>
	<b>Default:</b> By default; control is not passed on; and an unkown userID or rule will result in an Authorization Required reply. Not setting it thus keeps the system secure; and forces an NSCA compliant behaviour.
	<p>
	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.

	<p>
	See also <A HREF="core.html#authname">AuthName</A>,
	<A HREF="core.html#authtype">AuthType</A> and
	<A HREF="#authgroupfile">AuthGroupFile</A>.<p>

	<!--#include virtual="footer.html" -->
	</BODY>
	</HTML>