docs/manual/misc/FAQ-G.html - httpd - Git at Google

 <!--#if expr="$FAQMASTER" -->
  <!--#set var="STANDALONE" value="" -->
  <!--#set var="INCLUDED" value="YES" -->
  <!--#if expr="$QUERY_STRING = TOC" -->
   <!--#set var="TOC" value="YES" -->
   <!--#set var="CONTENT" value="" -->
  <!--#else -->
   <!--#set var="TOC" value="" -->
   <!--#set var="CONTENT" value="YES" -->
  <!--#endif -->
 <!--#else -->
  <!--#set var="STANDALONE" value="YES" -->
  <!--#set var="INCLUDED" value="" -->
  <!--#set var="TOC" value="" -->
  <!--#set var="CONTENT" value="" -->
 <!--#endif -->
 <!--#if expr="$STANDALONE" -->
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <HTML>
  <HEAD>
   <TITLE>Apache Server Frequently Asked Questions</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">Apache Server Frequently Asked Questions</H1>
   <P>
   $Revision: 1.1 $ ($Date: 1999/06/24 15:02:52 $)
   </P>
   <P>
   The latest version of this FAQ is always available from the main
   Apache web site, at
   &lt;<A
        HREF="http://www.apache.org/docs/misc/FAQ.html"
        REL="Help"
       ><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>&gt;.
   </P>
 <!-- Notes about changes:                                           -->
 <!--  - If adding a relative link to another part of the            -->
 <!--    documentation, *do* include the ".html" portion.  There's a -->
 <!--    good chance that the user will be reading the documentation -->
 <!--    on his own system, which may not be configured for          -->
 <!--    multiviews.                                                 -->
 <!--  - When adding items, make sure they're put in the right place -->
 <!--    - verify that the numbering matches up.                     -->
 <!--  - *Don't* use <PRE></PRE> blocks - they don't appear          -->
 <!--    correctly in a reliable way when this is converted to text  -->
 <!--    with Lynx.  Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL>    -->
 <!--    blocks inside a <P></P> instead.  This is necessary to get  -->
 <!--    the horizontal and vertical indenting right.                -->
 <!--  - Don't forget to include an HR tag after the last /P tag     -->
 <!--    but before the /LI in an item.                              -->
   <P>
   If you are reading a text-only version of this FAQ, you may find numbers
   enclosed in brackets (such as &quot;[12]&quot;).  These refer to the list of
   reference URLs to be found at the end of the document.  These references
   do not appear, and are not needed, for the hypertext version.
   </P>
   <H2>The Questions</H2>
 <OL TYPE="A">
 <!--#endif -->
 <!--#if expr="$TOC || $STANDALONE" -->
  <LI VALUE="7"><STRONG>Authentication and Access Restrictions</STRONG>
   <OL>
    <LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name
         working correctly?</A>
    </LI>
    <LI><A HREF="#user-authentication">How do I set up Apache to require
         a username and password to access certain documents?</A>
    </LI>
    <LI><A HREF="#remote-auth-only">How do I set up Apache to allow access
         to certain documents only if a site is either a local site
         <EM>or</EM> the user supplies a password and username?</A>
    </LI>
    <LI><A HREF="#authauthoritative">Why does my authentication give
         me a server error?</A>
    </LI>
    <LI><A HREF="#auth-on-same-machine">Do I have to keep the (mSQL)
         authentication information on the same machine?</A>
    </LI>
    <LI><A HREF="#msql-slow">Why is my mSQL authentication terribly slow?</A>
    </LI>
    <LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file
         for Web page authentication?</A>
    </LI>
   </OL>
  </LI>
 <!--#endif -->
 <!--#if expr="$STANDALONE" -->
 </OL>

 <HR>

   <H2>The Answers</H2>
 <!--#endif -->
 <!--#if expr="! $TOC" -->
   <H3>G. Authentication and Access Restrictions</H3>
 <OL>

  <LI><A NAME="dnsauth">
       <STRONG>Why isn't restricting access by host or domain name
       working correctly?</STRONG>
      </A>
   <P>
   Two of the most common causes of this are:
   </P>
   <OL>
    <LI><STRONG>An error, inconsistency, or unexpected mapping in the DNS
     registration</STRONG>
     <BR>
     This happens frequently: your configuration restricts access to
     <SAMP>Host.FooBar.Com</SAMP>, but you can't get in from that host.
     The usual reason for this is that <SAMP>Host.FooBar.Com</SAMP> is
     actually an alias for another name, and when Apache performs the
     address-to-name lookup it's getting the <EM>real</EM> name, not
     <SAMP>Host.FooBar.Com</SAMP>.  You can verify this by checking the
     reverse lookup yourself.  The easiest way to work around it is to
     specify the correct host name in your configuration.
    </LI>
    <LI><STRONG>Inadequate checking and verification in your
     configuration of Apache</STRONG>
     <BR>
     If you intend to perform access checking and restriction based upon
     the client's host or domain name, you really need to configure
     Apache to double-check the origin information it's supplied.  You do
     this by adding the <SAMP>-DMAXIMUM_DNS</SAMP> clause to the
     <SAMP>EXTRA_CFLAGS</SAMP> definition in your
     <SAMP>Configuration</SAMP> file.  For example:
     <P>
     <DL>
      <DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE>
      </DD>
     </DL>
     <P></P>
     <P>
     This will cause Apache to be very paranoid about making sure a
     particular host address is <EM>really</EM> assigned to the name it
     claims to be.  Note that this <EM>can</EM> incur a significant
     performance penalty, however, because of all the name resolution
     requests being sent to a nameserver.
     </P>
    </LI>
   </OL>
   <HR>
  </LI>

  <LI><A NAME="user-authentication">
       <STRONG>How do I set up Apache to require a username and
       password to access certain documents?</STRONG>
      </A>
   <P>
   There are several ways to do this; some of the more popular
   ones are to use the <A HREF="../mod/mod_auth.html">mod_auth</A>,
   <A HREF="../mod/mod_auth_db.html">mod_auth_db</A>, or
   <A HREF="../mod/mod_auth_dbm.html">mod_auth_dbm</A> modules.
   </P>
   <P>
   For an explanation on how to implement these restrictions, see
   <A HREF="http://www.apacheweek.com/"><CITE>Apache Week</CITE></A>'s
   articles on
   <A HREF="http://www.apacheweek.com/features/userauth"
   ><CITE>Using User Authentication</CITE></A>
   or
   <A HREF="http://www.apacheweek.com/features/dbmauth"
   ><CITE>DBM User Authentication</CITE></A>.
   </P>
   <HR>
  </LI>

  <LI><A NAME="remote-auth-only">
       <STRONG>How do I set up Apache to allow access to certain
       documents only if a site is either a local site <EM>or</EM>
       the user supplies a password and username?</STRONG>
      </A>
   <P>
   Use the <A HREF="../mod/core.html#satisfy">Satisfy</A> directive,
   in particular the <CODE>Satisfy Any</CODE> directive, to require
   that only one of the access restrictions be met.  For example,
   adding the following configuration to a <SAMP>.htaccess</SAMP>
   or server configuration file would restrict access to people who
   either are accessing the site from a host under domain.com or
   who can supply a valid username and password:
   </P>
   <P>
   <DL>
    <DD><CODE>deny from all
     <BR>
     allow from .domain.com
     <BR>
     AuthType Basic
     <BR>
     AuthUserFile /usr/local/apache/conf/htpasswd.users
     <BR>
     AuthName "special directory"
     <BR>
     require valid-user
     <BR>
     satisfy any</CODE>
    </DD>
   </DL>
   <P></P>
   <P>
   See the <A HREF="#user-authentication">user authentication</A>
   question and the <A HREF="../mod/mod_access.html">mod_access</A>
   module for details on how the above directives work.
   </P>
   <HR>
  </LI>

  <LI><A NAME="authauthoritative">
       <STRONG>Why does my authentication give me a server error?</STRONG>
      </A>
   <P>
   Under normal circumstances, the Apache access control modules will
   pass unrecognized user IDs on to the next access control module in
   line.  Only if the user ID is recognized and the password is validated
   (or not) will it give the usual success or &quot;authentication
   failed&quot; messages.
   </P>
   <P>
   However, if the last access module in line 'declines' the validation
   request (because it has never heard of the user ID or because it is not
   configured), the <SAMP>http_request</SAMP> handler will give one of
   the following, confusing, errors:
   </P>
   <UL>
    <LI><SAMP>check access</SAMP>
    </LI>
    <LI><SAMP>check user.  No user file?</SAMP>
    </LI>
    <LI><SAMP>check access.  No groups file?</SAMP>
    </LI>
   </UL>
   <P>
   This does <EM>not</EM> mean that you have to add an
   '<SAMP>AuthUserFile&nbsp;/dev/null</SAMP>' line as some magazines suggest!
   </P>
   <P>
   The solution is to ensure that at least the last module is authoritative
   and <STRONG>CONFIGURED</STRONG>. By default, <SAMP>mod_auth</SAMP> is
   authoritative and will give an OK/Denied, but only if it is configured
   with the proper <SAMP>AuthUserFile</SAMP>.  Likewise, if a valid group
   is required.  (Remember that the modules are processed in the reverse
   order from that in which they appear in your compile-time
   <SAMP>Configuration</SAMP> file.)
   </P>
   <P>
   A typical situation for this error is when you are using the
   <SAMP>mod_auth_dbm</SAMP>, <SAMP>mod_auth_msql</SAMP>,
   <SAMP>mod_auth_mysql</SAMP>, <SAMP>mod_auth_anon</SAMP> or
   <SAMP>mod_auth_cookie</SAMP> modules on their own.  These are by
   default <STRONG>not</STRONG> authoritative, and this will pass the
   buck on to the (non-existent) next authentication module when the
   user ID is not in their respective database.  Just add the appropriate
   '<SAMP><EM>XXX</EM>Authoritative yes</SAMP>' line to the configuration.
   </P>
   <P>
   In general it is a good idea (though not terribly efficient) to have the
   file-based <SAMP>mod_auth</SAMP> a module of last resort. This allows
   you to access the web server with a few special passwords even if the
   databases are down or corrupted.  This does cost a
   file open/seek/close for each request in a protected area.
   </P>
   <HR>
  </LI>

  <LI><A NAME="auth-on-same-machine">
       <STRONG>Do I have to keep the (mSQL) authentication information
       on the same machine?</STRONG>
      </A>
   <P>
   Some organizations feel very strongly about keeping the authentication
   information on a different machine than the webserver. With the
   <SAMP>mod_auth_msql</SAMP>, <SAMP>mod_auth_mysql</SAMP>, and other SQL
   modules connecting to (R)DBMses this is quite possible. Just configure
   an explicit host to contact.
   </P>
   <P>
   Be aware that with mSQL and Oracle, opening and closing these database
   connections is very expensive and time consuming. You might want to
   look at the code in the <SAMP>auth_*</SAMP> modules and play with the
   compile time flags to alleviate this somewhat, if your RDBMS licences
   allow for it.
   </P>
   <HR>
  </LI>

  <LI><A NAME="msql-slow">
       <STRONG>Why is my mSQL authentication terribly slow?</STRONG>
      </A>
   <P>
   You have probably configured the Host by specifying a FQHN,
   and thus the <SAMP>libmsql</SAMP> will use a full blown TCP/IP socket
   to talk to the database, rather than a fast internal device.  The
   <SAMP>libmsql</SAMP>, the mSQL FAQ, and the <SAMP>mod_auth_msql</SAMP>
   documentation warn you about this.  If you have to use different
   hosts, check out the <SAMP>mod_auth_msql</SAMP> code for
   some compile time flags which might - or might not - suit you.
   </P>
   <HR>
  </LI>

  <LI><A NAME="passwdauth">
       <STRONG>Can I use my <SAMP>/etc/passwd</SAMP> file
       for Web page authentication?</STRONG>
      </A>
   <P>
   Yes, you can - but it's a <STRONG>very bad idea</STRONG>.  Here are
   some of the reasons:
   </P>
   <UL>
    <LI>The Web technology provides no governors on how often or how
     rapidly password (authentication failure) retries can be made.  That
     means that someone can hammer away at your system's
     <SAMP>root</SAMP> password using the Web, using a dictionary or
     similar mass attack, just as fast as the wire and your server can
     handle the requests.  Most operating systems these days include
     attack detection (such as <EM>n</EM> failed passwords for the same
     account within <EM>m</EM> seconds) and evasion (breaking the
     connection, disabling the account under attack, disabling
     <EM>all</EM> logins from that source, <EM>et cetera</EM>), but the
     Web does not.
    </LI>
    <LI>An account under attack isn't notified (unless the server is
     heavily modified); there's no &quot;You have 19483 login
     failures&quot; message when the legitimate owner logs in.
    </LI>
    <LI>Without an exhaustive and error-prone examination of the server
     logs, you can't tell whether an account has been compromised.
     Detecting that an attack has occurred, or is in progress, is fairly
     obvious, though - <EM>if</EM> you look at the logs.
    </LI>
    <LI>Web authentication passwords (at least for Basic authentication)
     generally fly across the wire, and through intermediate proxy
     systems, in what amounts to plain text.  &quot;O'er the net we
     go/Caching all the way;/O what fun it is to surf/Giving my password
     away!&quot;
    </LI>
    <LI>Since HTTP is stateless, information about the authentication is
     transmitted <EM>each and every time</EM> a request is made to the
     server.  Essentially, the client caches it after the first
     successful access, and transmits it without asking for all
     subsequent requests to the same server.
    </LI>
    <LI>It's relatively trivial for someone on your system to put up a
     page that will steal the cached password from a client's cache
     without them knowing.  Can you say &quot;password grabber&quot;?
    </LI>
   </UL>
   <P>
   If you still want to do this in light of the above disadvantages, the
   method is left as an exercise for the reader.  It'll void your Apache
   warranty, though, and you'll lose all accumulated UNIX guru points.
   </P>
   <HR>
  </LI>
 </OL>
 <!--#endif -->
 <!--#if expr="$STANDALONE" -->
   <!-- Don't forget to add HR tags at the end of each list item.. -->

 <!--#include virtual="footer.html" -->
 </BODY>
 </HTML>
 <!--#endif -->
	<!--#if expr="$FAQMASTER" -->
	<!--#set var="STANDALONE" value="" -->
	<!--#set var="INCLUDED" value="YES" -->
	<!--#if expr="$QUERY_STRING = TOC" -->
	<!--#set var="TOC" value="YES" -->
	<!--#set var="CONTENT" value="" -->
	<!--#else -->
	<!--#set var="TOC" value="" -->
	<!--#set var="CONTENT" value="YES" -->
	<!--#endif -->
	<!--#else -->
	<!--#set var="STANDALONE" value="YES" -->
	<!--#set var="INCLUDED" value="" -->
	<!--#set var="TOC" value="" -->
	<!--#set var="CONTENT" value="" -->
	<!--#endif -->
	<!--#if expr="$STANDALONE" -->
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
	<HTML>
	<HEAD>
	<TITLE>Apache Server Frequently Asked Questions</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">Apache Server Frequently Asked Questions</H1>
	<P>
	$Revision: 1.1 $ ($Date: 1999/06/24 15:02:52 $)
	</P>
	<P>
	The latest version of this FAQ is always available from the main
	Apache web site, at
	<<A
	HREF="http://www.apache.org/docs/misc/FAQ.html"
	REL="Help"
	><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>>.
	</P>
	<!-- Notes about changes: -->
	<!-- - If adding a relative link to another part of the -->
	<!-- documentation, do include the ".html" portion. There's a -->
	<!-- good chance that the user will be reading the documentation -->
	<!-- on his own system, which may not be configured for -->
	<!-- multiviews. -->
	<!-- - When adding items, make sure they're put in the right place -->
	<!-- - verify that the numbering matches up. -->
	<!-- - Don't use <PRE></PRE> blocks - they don't appear -->
	<!-- correctly in a reliable way when this is converted to text -->
	<!-- with Lynx. Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL> -->
	<!-- blocks inside a <P></P> instead. This is necessary to get -->
	<!-- the horizontal and vertical indenting right. -->
	<!-- - Don't forget to include an HR tag after the last /P tag -->
	<!-- but before the /LI in an item. -->
	<P>
	If you are reading a text-only version of this FAQ, you may find numbers
	enclosed in brackets (such as "[12]"). These refer to the list of
	reference URLs to be found at the end of the document. These references
	do not appear, and are not needed, for the hypertext version.
	</P>
	<H2>The Questions</H2>
	<OL TYPE="A">
	<!--#endif -->
	<!--#if expr="$TOC \|\| $STANDALONE" -->
	<LI VALUE="7"><STRONG>Authentication and Access Restrictions</STRONG>
	<OL>
	<LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name
	working correctly?</A>
	</LI>
	<LI><A HREF="#user-authentication">How do I set up Apache to require
	a username and password to access certain documents?</A>
	</LI>
	<LI><A HREF="#remote-auth-only">How do I set up Apache to allow access
	to certain documents only if a site is either a local site
	<EM>or</EM> the user supplies a password and username?</A>
	</LI>
	<LI><A HREF="#authauthoritative">Why does my authentication give
	me a server error?</A>
	</LI>
	<LI><A HREF="#auth-on-same-machine">Do I have to keep the (mSQL)
	authentication information on the same machine?</A>
	</LI>
	<LI><A HREF="#msql-slow">Why is my mSQL authentication terribly slow?</A>
	</LI>
	<LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file
	for Web page authentication?</A>
	</LI>
	</OL>
	</LI>
	<!--#endif -->
	<!--#if expr="$STANDALONE" -->
	</OL>

	<HR>

	<H2>The Answers</H2>
	<!--#endif -->
	<!--#if expr="! $TOC" -->
	<H3>G. Authentication and Access Restrictions</H3>
	<OL>

	<LI><A NAME="dnsauth">
	<STRONG>Why isn't restricting access by host or domain name
	working correctly?</STRONG>
	</A>
	<P>
	Two of the most common causes of this are:
	</P>
	<OL>
	<LI><STRONG>An error, inconsistency, or unexpected mapping in the DNS
	registration</STRONG>
	<BR>
	This happens frequently: your configuration restricts access to
	<SAMP>Host.FooBar.Com</SAMP>, but you can't get in from that host.
	The usual reason for this is that <SAMP>Host.FooBar.Com</SAMP> is
	actually an alias for another name, and when Apache performs the
	address-to-name lookup it's getting the <EM>real</EM> name, not
	<SAMP>Host.FooBar.Com</SAMP>. You can verify this by checking the
	reverse lookup yourself. The easiest way to work around it is to
	specify the correct host name in your configuration.
	</LI>
	<LI><STRONG>Inadequate checking and verification in your
	configuration of Apache</STRONG>
	<BR>
	If you intend to perform access checking and restriction based upon
	the client's host or domain name, you really need to configure
	Apache to double-check the origin information it's supplied. You do
	this by adding the <SAMP>-DMAXIMUM_DNS</SAMP> clause to the
	<SAMP>EXTRA_CFLAGS</SAMP> definition in your
	<SAMP>Configuration</SAMP> file. For example:
	<P>
	<DL>
	<DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE>
	</DD>
	</DL>
	<P></P>
	<P>
	This will cause Apache to be very paranoid about making sure a
	particular host address is <EM>really</EM> assigned to the name it
	claims to be. Note that this <EM>can</EM> incur a significant
	performance penalty, however, because of all the name resolution
	requests being sent to a nameserver.
	</P>
	</LI>
	</OL>
	<HR>
	</LI>

	<LI><A NAME="user-authentication">
	<STRONG>How do I set up Apache to require a username and
	password to access certain documents?</STRONG>
	</A>
	<P>
	There are several ways to do this; some of the more popular
	ones are to use the <A HREF="../mod/mod_auth.html">mod_auth</A>,
	<A HREF="../mod/mod_auth_db.html">mod_auth_db</A>, or
	<A HREF="../mod/mod_auth_dbm.html">mod_auth_dbm</A> modules.
	</P>
	<P>
	For an explanation on how to implement these restrictions, see
	<A HREF="http://www.apacheweek.com/"><CITE>Apache Week</CITE></A>'s
	articles on
	<A HREF="http://www.apacheweek.com/features/userauth"
	><CITE>Using User Authentication</CITE></A>
	or
	<A HREF="http://www.apacheweek.com/features/dbmauth"
	><CITE>DBM User Authentication</CITE></A>.
	</P>
	<HR>
	</LI>

	<LI><A NAME="remote-auth-only">
	<STRONG>How do I set up Apache to allow access to certain
	documents only if a site is either a local site <EM>or</EM>
	the user supplies a password and username?</STRONG>
	</A>
	<P>
	Use the <A HREF="../mod/core.html#satisfy">Satisfy</A> directive,
	in particular the <CODE>Satisfy Any</CODE> directive, to require
	that only one of the access restrictions be met. For example,
	adding the following configuration to a <SAMP>.htaccess</SAMP>
	or server configuration file would restrict access to people who
	either are accessing the site from a host under domain.com or
	who can supply a valid username and password:
	</P>
	<P>
	<DL>
	<DD><CODE>deny from all
	<BR>
	allow from .domain.com
	<BR>
	AuthType Basic
	<BR>
	AuthUserFile /usr/local/apache/conf/htpasswd.users
	<BR>
	AuthName "special directory"
	<BR>
	require valid-user
	<BR>
	satisfy any</CODE>
	</DD>
	</DL>
	<P></P>
	<P>
	See the <A HREF="#user-authentication">user authentication</A>
	question and the <A HREF="../mod/mod_access.html">mod_access</A>
	module for details on how the above directives work.
	</P>
	<HR>
	</LI>

	<LI><A NAME="authauthoritative">
	<STRONG>Why does my authentication give me a server error?</STRONG>
	</A>
	<P>
	Under normal circumstances, the Apache access control modules will
	pass unrecognized user IDs on to the next access control module in
	line. Only if the user ID is recognized and the password is validated
	(or not) will it give the usual success or "authentication
	failed" messages.
	</P>
	<P>
	However, if the last access module in line 'declines' the validation
	request (because it has never heard of the user ID or because it is not
	configured), the <SAMP>http_request</SAMP> handler will give one of
	the following, confusing, errors:
	</P>
	<UL>
	<LI><SAMP>check access</SAMP>
	</LI>
	<LI><SAMP>check user. No user file?</SAMP>
	</LI>
	<LI><SAMP>check access. No groups file?</SAMP>
	</LI>
	</UL>
	<P>
	This does <EM>not</EM> mean that you have to add an
	'<SAMP>AuthUserFile /dev/null</SAMP>' line as some magazines suggest!
	</P>
	<P>
	The solution is to ensure that at least the last module is authoritative
	and <STRONG>CONFIGURED</STRONG>. By default, <SAMP>mod_auth</SAMP> is
	authoritative and will give an OK/Denied, but only if it is configured
	with the proper <SAMP>AuthUserFile</SAMP>. Likewise, if a valid group
	is required. (Remember that the modules are processed in the reverse
	order from that in which they appear in your compile-time
	<SAMP>Configuration</SAMP> file.)
	</P>
	<P>
	A typical situation for this error is when you are using the
	<SAMP>mod_auth_dbm</SAMP>, <SAMP>mod_auth_msql</SAMP>,
	<SAMP>mod_auth_mysql</SAMP>, <SAMP>mod_auth_anon</SAMP> or
	<SAMP>mod_auth_cookie</SAMP> modules on their own. These are by
	default <STRONG>not</STRONG> authoritative, and this will pass the
	buck on to the (non-existent) next authentication module when the
	user ID is not in their respective database. Just add the appropriate
	'<SAMP><EM>XXX</EM>Authoritative yes</SAMP>' line to the configuration.
	</P>
	<P>
	In general it is a good idea (though not terribly efficient) to have the
	file-based <SAMP>mod_auth</SAMP> a module of last resort. This allows
	you to access the web server with a few special passwords even if the
	databases are down or corrupted. This does cost a
	file open/seek/close for each request in a protected area.
	</P>
	<HR>
	</LI>

	<LI><A NAME="auth-on-same-machine">
	<STRONG>Do I have to keep the (mSQL) authentication information
	on the same machine?</STRONG>
	</A>
	<P>
	Some organizations feel very strongly about keeping the authentication
	information on a different machine than the webserver. With the
	<SAMP>mod_auth_msql</SAMP>, <SAMP>mod_auth_mysql</SAMP>, and other SQL
	modules connecting to (R)DBMses this is quite possible. Just configure
	an explicit host to contact.
	</P>
	<P>
	Be aware that with mSQL and Oracle, opening and closing these database
	connections is very expensive and time consuming. You might want to
	look at the code in the <SAMP>auth_*</SAMP> modules and play with the
	compile time flags to alleviate this somewhat, if your RDBMS licences
	allow for it.
	</P>
	<HR>
	</LI>

	<LI><A NAME="msql-slow">
	<STRONG>Why is my mSQL authentication terribly slow?</STRONG>
	</A>
	<P>
	You have probably configured the Host by specifying a FQHN,
	and thus the <SAMP>libmsql</SAMP> will use a full blown TCP/IP socket
	to talk to the database, rather than a fast internal device. The
	<SAMP>libmsql</SAMP>, the mSQL FAQ, and the <SAMP>mod_auth_msql</SAMP>
	documentation warn you about this. If you have to use different
	hosts, check out the <SAMP>mod_auth_msql</SAMP> code for
	some compile time flags which might - or might not - suit you.
	</P>
	<HR>
	</LI>

	<LI><A NAME="passwdauth">
	<STRONG>Can I use my <SAMP>/etc/passwd</SAMP> file
	for Web page authentication?</STRONG>
	</A>
	<P>
	Yes, you can - but it's a <STRONG>very bad idea</STRONG>. Here are
	some of the reasons:
	</P>
	<UL>
	<LI>The Web technology provides no governors on how often or how
	rapidly password (authentication failure) retries can be made. That
	means that someone can hammer away at your system's
	<SAMP>root</SAMP> password using the Web, using a dictionary or
	similar mass attack, just as fast as the wire and your server can
	handle the requests. Most operating systems these days include
	attack detection (such as <EM>n</EM> failed passwords for the same
	account within <EM>m</EM> seconds) and evasion (breaking the
	connection, disabling the account under attack, disabling
	<EM>all</EM> logins from that source, <EM>et cetera</EM>), but the
	Web does not.
	</LI>
	<LI>An account under attack isn't notified (unless the server is
	heavily modified); there's no "You have 19483 login
	failures" message when the legitimate owner logs in.
	</LI>
	<LI>Without an exhaustive and error-prone examination of the server
	logs, you can't tell whether an account has been compromised.
	Detecting that an attack has occurred, or is in progress, is fairly
	obvious, though - <EM>if</EM> you look at the logs.
	</LI>
	<LI>Web authentication passwords (at least for Basic authentication)
	generally fly across the wire, and through intermediate proxy
	systems, in what amounts to plain text. "O'er the net we
	go/Caching all the way;/O what fun it is to surf/Giving my password
	away!"
	</LI>
	<LI>Since HTTP is stateless, information about the authentication is
	transmitted <EM>each and every time</EM> a request is made to the
	server. Essentially, the client caches it after the first
	successful access, and transmits it without asking for all
	subsequent requests to the same server.
	</LI>
	<LI>It's relatively trivial for someone on your system to put up a
	page that will steal the cached password from a client's cache
	without them knowing. Can you say "password grabber"?
	</LI>
	</UL>
	<P>
	If you still want to do this in light of the above disadvantages, the
	method is left as an exercise for the reader. It'll void your Apache
	warranty, though, and you'll lose all accumulated UNIX guru points.
	</P>
	<HR>
	</LI>
	</OL>
	<!--#endif -->
	<!--#if expr="$STANDALONE" -->
	<!-- Don't forget to add HR tags at the end of each list item.. -->

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