mod_auth_db.html revision 1e895b30bf4833c928334fad80fac8be169ab877
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Apache module mod_auth_db</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">Module mod_auth_db</h1>
is not compiled in by default. It provides for user authentication using
files for those systems which support DB and not DBM. It is only
available in Apache 1.1 and later.
<menu>
<li><A HREF="#authdbgroupfile">AuthDBGroupFile</A>
<li><A HREF="#authdbuserfile">AuthDBUserFile</A>
<li><A HREF="#authdbauthoritative">AuthDBAuthoritative</A>
</menu>
<hr>
<A name="authdbgroupfile"><h2>AuthDBGroupFile</h2></A>
<!--%plaintext <?INDEX {\tt AuthDBGroupFile} directive> -->
<strong>Syntax:</strong> AuthDBGroupFile <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_db<p>
The AuthDBGroupFile directive sets the name of a DB 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 AuthDBGroupFile 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
AuthDBGroupFile unless otherwise protected.<p>
Combining Group and Password DB 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 DB file:<p>
<blockquote><code>
</code></blockquote>
The key for the single DB record 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 DB file after another colon; it is ignored by the
authentication module. <p>
<A HREF="#authdbuserfile">AuthDBUserFile</A>.<p><hr>
<A name="authdbuserfile"><h2>AuthDBUserFile</h2></A>
<!--%plaintext <?INDEX {\tt AuthDBUserFile} directive> -->
<strong>Syntax:</strong> AuthDBUserFile <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_db<p>
The AuthDBUserFile directive sets the name of a DB 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 AuthDBUserFile 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
AuthDBUserFile.<p>
Important compatibility note: The implementation of "dbmopen" in the
apache modules reads the string length of the hashed values from the
DB 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 DB files interchangeably between applications this may be a
part of the problem. <p>
<A HREF="#authdbgroupfile">AuthDBGroupFile</A>.<p>
<hr>
<A name="authdbauthoritative"><h2>AuthDBAuthoritative</h2></A>
<!--%plaintext <?INDEX {\tt AuthDBAuthoritative} directive> -->
<strong>Syntax:</strong> AuthDBAuthoritative < <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 AuthDBAuthoritative directive explicitly to <b>'off'</b>
allows for both authentication and authorization to be passed on
to lower level modules (as defined in the <code>Configuration</code>
<b>rule</b> matching the supplied userID. If there is a userID
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 conjunction with one of the basic auth
Whereas this DB 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 unknown
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>
<A HREF="#authdbgroupfile">AuthDBGroupFile</A>.<p>
<!--#include virtual="footer.html" -->
</BODY>
</HTML>