There are at least four ways you can limit access to your Web Pages.
1)  Require a "password" to be entered from your main page.
2)  Place your Web page under "htaccess" PASSWORD protection.
3)  Place your Web page under "htaccess" IP protection.
4)  Place your Web page under WebAuth protection.
Follow this link to a good tutorial on WebAuth.


1.  Require a "password" to be entered from your main page.

To do this, you simply add another input field:

Choose any "name" you like, as long as it doesn't conflict with any other names you are returning to your processing protocol.  The user enters a password, which isn't displayed because of TYPE="password".  When your protocol gets control, check the password value against the value(s) you allow.  If not correct, send back a text/plain page that tells the user they aren't allowed access.  Otherwise, do the actions your protocol would normally do to service this Web page.


2.  Place your Web page under "htaccess" PASSWORD protection.

This works for any kind of data, not just Web pages, and it blocks or allows access to everything in a particular directory.  Therefore, this technique requires you place anything that is to be protected in a single sub-directory of the "public_html" directory.  Of course you can have several sub-directories, each with its own protection.

Within the sub-directory, you place a hidden file called:  .htaccess     The contents of this file must contain "Auth..." tags that describe where .htpasswd and .htgroup files are located, what "name" you are using to identify this protection, and its type.  For the purposes of providing an example, assume there is an "emulator" sub-directory in "public_html" belonging to ~yourname.   Then:

AuthUserFile shows the fully-qualified path to the .htpasswd file.  AuthGroupFile shows the fully-qualified path to the .htgroup file.  AuthName shows the name that will be presented to the user when they try to access anything in the "emulator" directory.

You can place .htpasswd and .htgroup anywhere, but it is common practice to place them either in your home directory, or in a different directory from the .htaccess file.  In this example, both are together in the  /Users/yourname/  directory (home).

Here is an example of what .htgroup contains:

There could be more lines defining other groups.  In this case, the only group defined is the one specified at the end of .htaccess

The group name is terminated with a colon, and then followed by the usernames you require.  These do NOT have to be SunetID or logon names, just any names you want the user to enter to gain access.

Lastly, you must create the .htpasswd file.  You do this with the "htpasswd" command, a Unix command that is described in the manual (man htpasswd).  However, the save you time, I'll summarize here:

     htpasswd [ -c ] passwdfile username
     htpasswd -b [ -c ] passwdfile username password

In the first form, you are asked for the password, but with the -b option, you can supply it as the last parameter of the command.  The -c option says to create a new passwdfile.  Without -c, the passwdfile must already exist, and what you are doing is adding to it or altering an existing entry in it.

The "passwdfile" parameter is either a fully-qualified name, or relative path name.  The following are equivalent:

or

In the first case, it doesn't matter where you are in the file system.  In the second case, you are at /Users/yourname  (home directory).

Both examples show the creation of .htpasswd, destroying any prior version.  You would leave off the -c option if you were modifying.

Both examples show a username of "family".  That is NOT a logon name.  You would then be prompted for what password applies to "family".  You could include the -b option and end the command with the password.

You have now created the .htpasswd file in the same directory as the .htgroup file.  All of these files need to be readable by the public, therefore I recommend the following command:

That sets read-permissions for these files, when you are in the proper directory.

Now, you can add another username and password by issuing another htpasswd command, but without the -c option.  If the username already exists in the target passwdfile, then the old password will be replaced by a new password.  If the username doesn't exist, the given username will be added with the given password.

If you add a new username to .htpasswd, then you'll probably need to update the .htgroup file to append that username to the group's name list.  In the original example of .htgroup, both "emuser" and "family" were listed.  So I could add "emuser" to .htpasswd with the htpasswd command without having to change .htgroup since that username is already listed there.

When the Web Server accesses the sub-directory containing the object it is supposed to retrieve (index.html, anyother.html, compressed.hqx, FILE.DEFQ), and there is a .htaccess file in the same sub-directory, then the Web Server presents a dialog box to the user.  The AuthName is shown, and the user must enter a Name and Password, corresponding to a matching username and password in the associated .htpasswd file, and same username listed in the required group found in the associated .htgroup file.  If the user can successfully Login, then the requested object is retrieved.  Note that if the object isn't an html page, it can be any other kind of object with a suffix listed in the AddType entries of the .htaccess file.  Such objects are usually downloaded and handled by the "application" specified, or are just downloaded as "binary" objects (DEFQ, REC1, etc).


3.  Place your Web page under "htaccess" IP protection.

You can also do a really simple access restriction based on the IP address via the .htaccess file.  For things that are under development or something like that, you might find this a much simpler method than passwords.  Just enter the IP address or range of addresses that you want to allow.

Here's a sample .htaccess file:

That's all it takes.  This allows connections only from a very certain set of IPs (all those ending in stanford.edu, or rlg.org or the others shown, and all those beginning with 124.87).

This is not 100% secure; it is possible that someone could try to spoof an IP address, but for simple purposes it is fine.

This kind of restriction is also nice because it easily keeps out webcrawling robots, which, once they start getting into the database pages, often get caught following link after link, generating huge numbers of searches, loading the webserver.

For more detailed information about .htaccess files, visit the following web site: http://httpd.apache.org/docs-2.0/howto/auth.html
Note that you can ignore all the Prerequisits and discussion having to do with the webserver.  Just concentrate on the Directives.

Click on this link to return to the main SUSPIRES index.