Restricting Access to Web Pages

Why Password Protect Web Pages?

Users frequently want to share information with a limited number of people. This may be project material, sensitive information, or information that is specific to WPI and thus doesn't need to be world-readable. In these cases, or any others, it is possible to restrict the access to your web site with a password or enable machine-specific access (for example: by IP address).

Possible Restrictions

There are three ways to restrict access to a directory for web pages using the .htaccess method. You can restrict access by configuring a username and password system for specific individuals or groups, access can be restricted by specifying a machine name or IP address, or you can restrict access to a certain domain using the domain name or address.

Automated Processes for Class Web Page Access Restriction

If you are a faculty member at WPI and you want to restrict access to a web site to members of a certain class you can do that using the classlist command at the UNIX prompt.

Configuring the .htaccess File

What's the Easy Answer...?

Simplest example of an .htaccess file is here.

For the .htaccess file to work properly it must be located in the top level of the directory structure you want to protect. Thus, if you wanted to protect your entire personal web site you would put the .htaccess file in your public_html directory, but if you only wanted to protect the contents of your "Project" directory within your web site the file would go in public_html/Project/. Note: All subdirectories are also affected by the .htaccess protection, so public_html/Project/Stuff/ would also be restricted by both .htaccess files mentioned here.

Sample .htaccess file:

	AuthUserFile /home/your-username/.htpasswd
	AuthGroupFile /home/your-username/.htgroup

	AuthType Basic
	AuthName "Nifty Little Title"

	order deny,allow
	allow from .wpi.edu
	deny from misuser.wpi.edu
	require valid-user

In order to work a .htaccess file needs to have specified limits, these are the directives which determine who can and can not access the web pages. The directives are the third group of items above. There are also a few associated files, listed above in blue, which are associated with the username/password method of access restriction. AuthName sets the name of the authorization realm for the directory. It is a short name which can contain spaces.

Command	Modifiers	Description
AuthType	basic, EGnetID	AuthType specifies the type of authorization allowed. It must always be included in your .htaccess file.
AuthName	"Descriptive text"	This directive specifies the title of the password prompt when it is displayed to a visitor. Only applies to basic auth. See also the directive "PubcookieAppID".
PubcookieAppID	"Site name"	This directive should be used when AuthType is EGnetID. It is used to specify that all pages under this .htaccess file have the same authorization requirements, and thus a logged-in user should have access to those pages. Failure to specify this directive may result in strange problems with images or CSS. The "Site name" may contain only letters, numbers, and spaces. The "Site name" cannot contain special characters like: !@#$%^&*()-=_+[]{};':",.<> Due to an encoding bug, using these characters will result in visitors endlessly redirecting to the Pubcookie login page.
order	deny,allow	This directive, which must be listed before the others within the `Limit` tags, tells the server what in what order the deny and allow requests are processed. By default the deny directives are processed first.
allow from	hostname(s), domain name, full IP address, partial IP address, all	The `allow` directive specifies which hosts are allowed access to your directory. You can specify the hostname (i.e. reno.wpi.edu), the domain (for WPI this would be .wpi.edu), an IP address (like 130.215.20.20), a partial IP address (like 130.215.x.x), or all (everyone). There can only be one `allow` directive in each `Limit` specification, but you can have multiple modifiers. (So, for example, you could include 250 IP addresses, if you wanted, or specify 15 hostnames.)
deny from	hostname(s), domain, full IP address, partial IP address, all	The `deny` directive specifies which hosts are denied access to your directory. It uses the same modifiers as the `allow` directive, described above.
require	user, group, valid-user	The `require` directive helps define individual access to a directory, and is used in conjunction with the .htpasswd and/or .htgroup files. User specifies a specific individual whose username is found in the .htpasswd file, group specifies the name of a group to which any number of usernames can be assigned, and valid-user allows access for all individuals listed in the specified password file. More information on setting up individual and group access can be found below.
AuthUserFile	[absolute path]/filename	This command specifies the path to the file which contains the list of users and passwords, valid if you are using the `require` directive to limit access to your directory. More information on setting up individual and group access can be found below.
AuthGroupFile	[absolute path]/filename	This command specifies the path to the file which contains the list of groups and their members, valid if you are using the `require` directive to limit access to your directory. More information on setting up individual and group access can be found below.

What the Above .htaccess File Does

The first thing that is processed is the AuthType, which is set to basic. This enables the password protection of the web pages. Afterwards the AuthName is set, and then the location of the password and group files is set.

Next the directives within the Limit tags are processed. The order is set to deny and then allow, so the server first looks at the deny directive. It is set to restrict anyone from the machine misuser.wpi.edu from accessing the directory. However, the next allow directive enables any machine from .wpi.edu, including the misuser.wpi.edu machine, to access the directory. You will want to pay careful attention to the order in which you specify allows and denies, then, so you don't override one set of instructions with another and accidentally allow or deny access.

Finally the require directive is processed. The access has already been restricted to machines in the .wpi.edu domain, and the require directive specifies that only one user, named "username," can access this site. So we have just set up restrictions so that only valid users, from any machine within the .wpi.edu domain, can access this site. They still need to remember their password, though!

This may be a little too restrictive for general use, but it shows the steps the server will take in determining from where (and sometimes who), can access the directory. A more basic example, allowing access to anyone in the specified AuthUserFile, would be:

	AuthUserFile /home/your-username/.htpasswd
	AuthType Basic
	AuthName "Nifty Little Title"
	require valid-user

REMEMBER: The .htaccess file must have the proper permissions. The easiest way to set this is to run the command chmod 704 .htaccess in the directory which contains your .htaccess file so that only you and the web browser have the ability to read the file.

Sample .htaccess file which authenticates any WPI user

The following .htaccess file uses Pubcookie to prompt the visitor for a valid WPI Unix login/password.

	  PubcookieAppID "TILT Admin"
	  AuthType EGNetID
	  require valid-user

Sample .htaccess file which authenticates specific WPI users

The following .htaccess file prompts the visitor for a valid WPI Unix login/password but only allows username1 and username2 access.

	  PubcookieAppID "TILT Admin"
	  AuthType EGNetID
	  require user username1 username2

After logging into the PubCookie login page, the visitor will be automatically sent back to your page. However, any pages restricted to WPI users must be accessed as "HTTPS" rather than plain "HTTP". PubCookie will automatically use HTTPS, but advanced users could rewrite those URLS incorrectly. Doing so will deny access to the affected page.

Configuring the .htpasswd and .htgroup Files

To specify individual access to a directory you must set up a password file, traditionally named .htpasswd, and if you want to be able to specify groups of users you will also need a group file, traditionally called .htgroup. The passwords in the .htpasswd file are encrypted, so you can leave them within the world-readable web directories, but since they would be publicly available there is the chance that someone could crack them. The best option is to place them in a more secure location if you have are worried about this.

Configuring Individual Access

Once you have defined a .htaccess file and you know the individual users who will be granted access to your directory you need to run the htpasswd program. (Type htpasswd at the UNIX prompt, using the modifiers described below.) You can run this in the same directory you want the .htpasswd file to appear in, or enter the path to the directory where you want the file kept.

The htpasswd program takes a few modifiers. The first time you run it, you need to type: htpasswd -c /path/filename username. (Note that you do not need to enter the path if you are running htpasswd in the directory the file will be placed in.) The -c flag tells the program to create a new file named filename (.htpasswd is the standard name to use). username is the name of the person you want to add. You will automatically be prompted to enter a password for this person, and asked once more to confirm the password.

Adding Users: After you have run the htpasswd program and have created a password file you can add additional users by running the program without the -c flag. It would look something like this when adding users:

htpasswd /path/.htpasswd user1 where the path is specified to the file ".htpasswd" and user1 is a new user.

Changing A User's Password: Once you have added someone to the .htpasswd file you can change their password by running the command used to add a new user (see above). Instead of creating a new user, however, the program will prompt you to change the password for the existing user.

Deleting A User: To delete a user you will need to use a text-editor like emacs or pico and modify the file directly. To remove the above user, user1, from our .htpasswd file you can type pico .htpasswd when you're in the same directory as the file, and remove the line with user1's name and password. (It will look something like user1: 34SE2CKI(X*)

Configuring Group Access

After you have specified a group using the require directive in the .htaccess file, and have created a number of users with the htpasswd program, you can create a .htgroup file and add users to user groups in it. To create the file just use a text editor, like emacs or pico and make a new file with the same name as you have specified in the AuthGroupFile directive. (The traditional name of this file is .htgroup). The format used for groups is: groupname: user user1 user2 ..., where users are individuals who have been added to the password file.

Groups are not necessary if you have only one username specified for access to your directory, and are most useful when you have a number of different users with different passwords who are accessing your directory. Most people will therefore never need to use the group directive.

Maintained by itweb.
Last modified: Feb 15, 2021, 18:26 UTC