|
PDF Available |
|
|
PDF Available |
Abstract
NERSP's Web server provides a facility to allow you to restrict access to your web pages; either via userid/password challenge, or IP address exclusion, or combinations of the two. This security facility is invoked automatically by the presence of a file named .htaccess in the directory to be secured. You must create this file and place it into the directory you wish to be password-protected.
<editor@cns.ufl.edu>Table of Contents
NERSP's Web server provides a facility to allow you to restrict access to your Web pages; either via userid/password challenge, or IP address exclusion, or combinations of the two. This security facility is invoked automatically by the presence of a file named .htaccess in the directory to be secured. You must create this file and place it into the directory you wish to be password-protected.
This mode lets you restrict access to a given subdirectory under your public_html subdirectory, via userid and password. It restricts access to all files in the subdirectory, to only those individuals who can present a userid and password which match those stored in a file that you create for that specific purpose. It cannot be used to protect individual files within a subdirectory: it applies to all files within the affected subdirectory. The userids you create to govern access via this method are arbitrary; they do not have to correspond in any way with system logon usernames.
The following sample .htaccess file can be copied, edited as desired, and saved in the subdirectory you wish to protect. Lines with "#"' in the left-most position are comment lines.
Figure 1. Sample .htaccess File
# SAMPLE .htaccess file for use on NERSP.CNS.UFL.EDU
# Lines starting with "#" are comments.
# This file MUST be named .htaccess and it must be located in the
# directory to be protected.
#
# Set the access order to deny all and then allow userids in the
# Authorized User File ("AuthUserFile").
Order deny,allow
#
# The AuthUserFile is a path to the file (named "friends" in this example) that
# holds the list of users you want to have access to the subdirectory you wish
# to secure (named "secret" in this example). Save it in your home directory
# or some other NON-world-readable subdirectory. DO NOT SAVE IT IN THE
# SUBDIRECTORY ("secret") TO BE SECURED.
#
# Substitute: "userid"=Your NERSP Userid
#
# Substitute: "friends"=File of approved userids/passwords YOU create
# using htpasswd (see below). It is NOT required that this file be in
# your home directory (/u/userid). It may be in any subdirectory in
# which you have WRITE permission. However, it should not be in a
# "world-readable" directory (such as "public_html" or any of its
# subdirectories, including your "secret" subdirectory), for security reasons.
AuthUserFile /u/userid/friends
#
# The AuthGroupFile isn't important for what you want to do, but
# it needs to be defined anyway.
AuthGroupFile /dev/null
#
# The AuthName is the phrase that comes up in the "Enter Network Password"
# dialog box.
# Substitute: "The name of your resource goes here."= The information you wish
# displayed to the users at that log-in prompt. This should usually be the name
# of the resource being accessed. If more than one word is used, then the
# AuthName string must be in "quotes".
AuthName "The name of your resource goes here."
#
# The AuthType is the communications method for transmission of
# authentication data. 'Basic' is all you will need.
AuthType Basic
# Here's the command which actually invokes the security restriction.
# Note that the limit methods ("GET", "POST", & "PUT" in this example)
# must be entered in ALL UPPER CASE.
<Limit GET POST PUT>
require valid-user
</Limit>
#
# Save this file as .htaccess in your NERSP secure subdirectory.
Copy the above example file (see "Figure 1 .htaccess File") and edit it according to the tips given in the comment lines.
While in the subdirectory where the .htaccess file is located, change the MODE settings for it with the command:
chmod 644 .htaccess
This will set the access flags for .htaccess to:
-rw-r--r--
Create a userid/password file (see "Creating Your Userid/Password File: htpasswd" below).
The file containing the list of approved userids and passwords (friends in our example) is created and populated using the htpasswd utility. This file can be located in your NERSP home directory or any of your subdirectories: however, it should NOT be located in a "world-readable" directory such as public_html; this is to prevent the list of approved userids and passwords from being disclosed to the general public. Even though the passwords in this file are encrypted, access to it could give a "hacker" a head-start in compromising your security.
Change directories (cd) to the directory in which you wish the userid/password file to be located.
Create the file using the appropriate syntax for the htpasswd command: htpasswd [-c] where:passwordfilename username
passwordfilename is the name of the file which holds the usernames and passwords which will control access to your secure directory, and
username is the username you wish to add to the file.
The -c option stands for "create" and is only used the first time you run htpasswd for a given username file (i.e., to add the first username). Thereafter, you use htpasswd without the
-c option. The brackets [ ] are used in the above example to indicate an optional switch; remove the brackets from the -c switch before entering the command to create a new file.
You will be prompted twice for the password to be assigned. To eliminate a userid from the list, edit the file (using pico, vi, or other editor of your choice), and delete the line with that userid.
Once the .htaccess file shown above is in place with correct permissions, set using the command:
chmod 644 passwordfilename
and the corresponding userid/password file created (with correct permissions), then any subsequent attempt by a Web-browser to access files in the protected directory will result in the browser displaying a dialog box requesting a
User name and Password.
This example is from MS-Internet Explorer.
When these are entered correctly, the requested file will be displayed.
Once the user has been authenticated through this process (having supplied a valid username/password combination, as defined in the file designated by the AuthUserFile parameter of the .htaccess file), that user will
have normal access to all files in the protected subdirectory for the duration of his Web browser session. The user will not be challenged again until after he quits (exits) his Web browser program. Then, the next time he launches a Web browser, and
requests a protected page, he will again be prompted for his userid and password, prior to being allowed to view/access the page.
NERSP's Web server lets you specify which IP addresses may access files in certain directories. The restrictions are specified in a file named .htaccess, which is placed in the directory that contains the pages/data to be restricted.
Assume an IP address of the form "w.x.y.z" and that all users with IP addresses in the range defined by "w.x.y" are to be given access to all the files in a particular subdirectory.
The following .htaccess file (Figure 2, Sample .htaccess for IP exclusion) would be placed in that subdirectory. (See Figure 1 Sample .htaccess File for a more detailed explanation of the contents of .htaccess). Lines with # in the left-most position are comment lines.
Figure 2. Sample .htaccess file for IP exclusion
AuthGroupFile /dev/null
AuthType Basic
<Limit GET POST PUT>
order deny,allow
#
# "deny from all" says, "First we will exclude everyone."
# Then we will use the "allow..." statement to designate who is allowed
# access. Note that the "order" statement above specifies that we
# want to process "deny" directives first, followed by "allow"
# directives. The result of this is that the "allow" directives
# serve as an override or modification of the "deny" directives.
#
deny from all
#
# Replace "w.x.y" with the IP range you wish to allow access to these
# files: for example, "128.227.123". You can narrow the range
# to a single address if you desire, e.g. "128.227.123.253".
# You may also have multiple "allow from..." statements, if needed.
#
allow from w.x.y
#
# NOTE: You may also "allow from .domain.name";
# e.g. "allow from .ufl.edu", or "allow from.cns.ufl.edu".
#
</Limit>
Edit the .htaccess file, replacing w.x.y with the domain that is not excluded.
While in the subdirectory where the .htaccess file is located, change the MODE settings for it with the command:
chmod 644 .htaccess
This will set the access flags for .htaccess to:
-rw-r--r--
It is possible to combine restriction directives in your .htaccess file, such that it will require a user to both present an authorized userid and password AND to be within a specified range of
IP addresses (or a specific DNS domain).
The key to this type of restriction is simply including both types of restriction within the <Limit>...</Limit> section of your .htaccess file, as shown in the example below.
(See the previous examples [above] for a more detailed explanation of the contents of .htaccess.) Lines with # in the left-most position are comment lines.
Figure 3. Sample .htaccess code with both IP and password exclusion
AuthGroupFile /dev/null
AuthUserFile /u/userid/friends
AuthName "The name of your resource goes here."
AuthType Basic
<Limit GET POST PUT>
deny from all
#
# If multiple restrictions are specified (as below), then the default
# behavior is to require that they ALL be satisfied before
# access is granted.
#
# Replace "w.x.y" with the IP range you wish to allow access to
# these files: for example, "128.227.123". You can narrow the
# range to a single address if you desire, e.g. "128.227.123.253".
#
allow from x.y.z
#
# NOTE: You may also "allow from .domain.name";
# e.g. "allow from .ufl.edu".
#
require valid-user
#
</Limit>
Use the htpasswd command, as described above, to create the userid/password file which (in conjunction with your specified IP address-range restrictions) controls access to the Web pages protected by this
.htaccess file.
While in the subdirectory where the .htaccess file is located, change the MODE settings for it with the command:
This will set the access flags for .htaccess to:
This type of restriction would be used when you want everyone within a certain IP address range (your office LAN, for example), to be able to freely access certain pages; however, you still want to allow limited access (controlled by userid/password) for individuals outside your restricted domain (e.g., users dialing in from home).
The key to this type of restriction is simply including the satisfy any directive within the <Limit>...</Limit> section of your .htaccess file, in addition to both types of restriction as shown in the example below. (See Figure 1 "Sample .htaccess File" for a more detailed explanation of the contents of .htaccess.) Lines with # in the left-most position are comment lines.
Figure 4. Sample .htaccess code with either IP or password exclusion
AuthGroupFile /dev/nul
AuthUserFile /u/userid/friends
AuthName "The name of your resource goes here."
AuthType Basic
<Limit GET POST PUT>
deny from all
allow from x.y.z
# NOTE: You may also "allow from .domain.name";
# e.g. "allow from .ufl.edu".
require valid-user
satisfy any
</Limit>
Set up your .htaccess file usipng the sample code in Figure 4 above. Edit the sample with information specific to your configuration.
Use the htpasswd command, as described above, to create the userid/password file which (in conjunction with your specified IP address-range restrictions) controls access to the Web pages protected by this
.htaccess file.
While in the subdirectory where the .htaccess file is located, change the MODE settings for it with the command:
chmod 644 .htaccess
This will set the access flags for .htaccess to:
-rw-r--r--
Your .htaccess file and its corresponding username/password file (if any) restrict access to the subdirectory in which .htaccess is located, and all subdirectories below it. This
inheritance can be over-ridden by placing another .htaccess file in one of the subsidiary subdirectories, in which case the restrictions imposed by each .htaccess file apply to the
directory in which it is located and are inherited downward from that point.
We welcome your comments and suggestions on this and all CNS documentation. Please send your comments to:
UF Computing & Networking Services
112 Bryant Space Sciences Bldg, University of Florida