asg15.htm

apache技术手册

<FONT SIZE=4 COLOR="#FF0000"><B>The </B><B>allow</B><B> Directive</B></FONT></CENTER></H4>

<BR>

<P>The allow directive lists hosts that are allowed access to the directory. allow has the following syntax:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">allow from <I>host</I> <I>host</I>...</FONT></PRE>

<P><I>host</I> can be specified by [all] | [<I>fully qualified host name</I>] | [<I>partial </I><I>domain name</I>] | [<I>IP address</I>] | [<I>partial IP address</I>].

<BR>

<BR>

<A NAME="E69E183"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>The </B><B>deny</B><B> Directive</B></FONT></CENTER></H4>

<BR>

<P>The deny directive lists hosts that are denied access to the directory. deny has the following syntax:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">deny from <I>host</I> <I>host</I>...</FONT></PRE>

<P><I>host</I> can be specified by [all] | [<I>fully qualified host name</I>] | [<I>partial </I><I>domain name</I>] | [<I>IP address</I>] | [<I>partial IP address</I>].

<BR>

<BR>

<A NAME="E69E184"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Host-based Access Control Example</B><B>s</B></FONT></CENTER></H4>

<BR>

<P>To limit access control to your server's DocumentRoot to hosts in your domain (assuming that your document root is htdocs), you would have an entry in your conf/access.conf file that looks like this:

<BR>

<PRE>

<FONT COLOR="#000080">&lt;Directory /usr/local/etc/httpd/htdocs&gt;

&lt;Limit GET POST&gt;

order deny,allow

deny from all

allow from <I>yourdomain.dom</I>

&lt;/Limit&gt;

&lt;/Directory&gt;</FONT></PRE>

<P>If you were limiting access to a directory inside your DocumentRoot (using .htaccess), you would specify this:

<BR>

<PRE>

<FONT COLOR="#000080">&lt;Limit GET POST&gt;

order deny,allow

deny from all

allow from <I>yourdomain.dom</I>

&lt;/Limit&gt;</FONT></PRE>

<P>As described in the syntax, you can also specify hosts by IP or partial IP address. Using an IP address to list hosts may be more secure than by name. The following is a more complex example. To only allow access to hosts in the <I>your.domain</I> domain and the marketing subnet of the friendly.com domain and to all hosts from network 204.95.160 (in this case, this is a C class address so there are 254 possible hosts), the &lt;Limit&gt; section would look like this:

<BR>

<PRE>

<FONT COLOR="#000080">&lt;Limit GET POST&gt;

order deny,allow

deny from all

allow from yourdomain.dom marketing.friendly.com 204.95.160

&lt;/Limit&gt;</FONT></PRE>

<BR>

<A NAME="E68E166"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>User Authentication Control</B></FONT></CENTER></H3>

<BR>

<P>User authentication allows you to control access to the document tree on an individual user basis by utilizing user and passwords lists to provide the necessary authentication. When a user accesses a restricted portion of the site, the server requires him to log in by specifying a username and a password. If the user supplies the proper information, access is granted for him to roam across the site without additional login requests. (Although the user does not enter a password, the username and password get re-sent by the browser with each new request to the protected realm.) See Figure 15.1 for an example of a login panel and Figure 15.2 for an example of a rejected login.

<BR>

<P><B> <A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/Apachu/15asg01.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/Apachu/15asg01.gif'" tppabs="http://docs.rinet.ru:8080/Apachu/15asg01.gif">Figure 15.1. A login panel. The message </B><B>You need a </B><B>password to access this page</B><B> was added by the </B><B>AuthName</B><B> directive.</A></B>

<BR>

<P><B> <A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/Apachu/15asg02.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/Apachu/15asg02.gif'" tppabs="http://docs.rinet.ru:8080/Apachu/15asg02.gif">Figure 15.2. A rejected login. This is the </B><B>message Apache displays if the client doesn't provide the correct </B><B>authentication information.</A></B>

<BR>

<P>User <A NAME="I3"></A>authentication based on access control provides more selective security because access permission is validated on a per-user basis. Apache requires login and a password validation before granting access to a restricted portion of your site. It is important to note that there is no correlation between the UNIX password file (/etc/passwd) and the server's password files; it is not necessary for a user to have an account on your system to be able to access protected materials on your Web server. Also, it goes without saying that security is only as good as the passwords and the secrecy used to guard them.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE>Because passwords are transmitted as encoded text, there are no safeguards preventing someone from intercepting a request and decoding the password. The security of your information really depends on the trustworthiness of the networks used to access your server; a condition that is nonexistent when your server is accessed from the Internet.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>To provide user authentication you will need to create and maintain password files. You can have many different password files within your site; however, you may find it easier to create a single password file and create a group file to further refine permissions. By also using a group file, you can establish access restrictions based on the user's group memberships.

<BR>

<P>Currently, user authentication is provided by the following modules:

<BR>

<UL>

<LI>mod_auth&#151;Authentication using flat file databases

<BR>

<BR>

<LI>mod_auth_dbm&#151;Authentication using DBM (hashed database) files

<BR>

<BR>

<LI>mod_auth_db&#151;Authentication using the Berkeley Software Distribution (BSD) UNIX DB files (BSD's hashed database format). This module is included in Apache 1.1. Users of Apache 1.0.<I>x</I> can find the module on the Apache site under third-party contributions.

<BR>

<BR>

</UL>

<P>The previous modules provide the following directives:

<BR>



<TABLE  BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 WIDTH="80%" CELLPADDING=2 >

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<BR>

<P ALIGN=CENTER>

<CENTER>

<FONT COLOR="#000080"><B>Module</B></FONT></CENTER>

<BR>

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<BR>

<P ALIGN=CENTER>

<CENTER>

<FONT COLOR="#000080"><B>User Authentication Directive</B></FONT></CENTER>

<BR>

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

mod_auth

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

AuthUserFile <I>file</I>

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

mod_auth_dbm

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

AuthDBMUserFile <I>dbmfile</I>

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

mod_auth_db

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

AuthDBUserFile <I>dbfile</I></FONT>

</TABLE><P>The only difference between the modules, besides the small change in the naming of the directive, is the database format used to store the user and password information. The modules providing DBM and DB support offer incredible performance enhancements over the flat files used by mod_auth. DBM and DB formats are hashed tables. A <I>hashed</I> <I>table</I> orders all entries with a unique index, otherwise known as a <I>key</I>, which is generated from the username and a value. In order to look up a password, the hashing algorithm computes the key for the user and retrieves the password. In contrast, the flat file version (mod_auth) needs to read every user in the file, and when it finds a match, it retrieves it. This process becomes very inefficient and slow as soon as there are more than a few hundred users in the database.

<BR>

<P>The DBM version of the module was originally developed for HotWired (<A HREF="javascript:if(confirm('http://www.hotwired.com/  \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address.  \n\nDo you want to open it from the server?'))window.location='http://www.hotwired.com/'" tppabs="http://www.hotwired.com/"> http://www.hotwired.com</A>), which has over 150,000 users.

<BR>

<BR>

<A NAME="E69E185"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Requesting a Password</B></FONT></CENTER></H4>

<BR>

<P>To request authentication for your document tree to users within your network, just modify your access.conf configuration file to have an entry like this:

<BR>

<PRE>

<FONT COLOR="#000080">&lt;Directory /usr/local/etc/httpd/htdocs&gt;

 AllowOverride None

<I> </I><I>AuthUserFile /usr/local/etc/httpd/passwords/passwordfile</I>

<I># Group authentication is disabled by pointing it to /dev/null</I>

 AuthGroupFile /dev/null

 AuthName These documents are only available to authorized users in our domain name

 AuthType Basic

 &lt;Limit Get&gt;

 require valid-user

 order deny,allow

 deny from all

 allow from <I>domain</I>

 &lt;/Limit&gt;

&lt;/Directory&gt;</FONT></PRE>

<P>The order, deny, and allow directives limit who will get a login panel. If you want users to be able to use your server from outside your network, just omit these directives. Otherwise, just replace <I>domain</I> with the domain name for your organization, or better yet, specify your domain by using an IP address notation.

<BR>

<P>The previous example defines the location of the database using the AuthUserFile and AuthGroupFile directives provided by the mod_access module. If you wish to use the DBM or DB supporting modules, just replace the authentication configuration directives with the equivalent version provided by the module you wish to use.

<BR>

<P>Next, you'll need to create the password directory on your httpd tree:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080"># mkdir /usr/local/etc/httpd/passwords</FONT></PRE>

<P>Make sure the /usr/local/etc/httpd/ passwords directory is readable by the user or group your server runs under. If the server cannot access the file, no one will be able to get in.

<BR>

<P>The tools you use to manage the password file depend on the type of authentication you use. If you are using flat files, you'll use the htpasswd program. If you are using database files, you'll use the dbmmanage script.

<BR>

<BR>

<A NAME="E69E186"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Managing Flat-File Password</B><B> Files with </B><B>htpasswd</B></FONT></CENTER></H4>

<BR>

<P>To add users to your password file, you'll need to use the htpasswd program. The source code for this program is included in the support directory (/usr/local/etc/httpd/support), but it is not compiled by default. You'll need to edit the CC= directive in the makefile in that directory to match the name of your compiler. And then issue a make. After a few seconds, the binary htpasswd and other utilities will be built. Once htpassword is built, you can create a password file. The htpasswd program has the following syntax:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">htpasswd [-c] passwordfile username</FONT></PRE>

<P>The -c flag creates the password file <I>passwordfile</I>. Here's a sample session:

<BR>

<PRE>

<FONT COLOR="#000080"># cd /usr/local/etc/httpd

# support/htpasswd -c passwords/passwordfile <I>user</I>

Adding password for <I>user</I>.