Restricting Access (Non-Columbia)

Web Design > Restricting Access (Non-Columbia)

If you need to provide access to your documents for users that do not have any Columbia affiliations and therefore do not have UNI's, you may create and maintain your own list of users and passwords. There are two methods for creating a list of users and their passwords — one for the secure server and one for the regular server. (If you are going to combine your own list of users with those who may log in using their UNI's, then you are required to use the secure server.)

Using the Secure Server

The .htaccess File

If you choose to create a local database of users, their passwords, and groups; then you should put the line:

AuthKrbUserType udb

in the .htaccess file. You will need additionally to add the line:

AuthKrbUserFile full-path-to-mydbfile-webacl.udb

where full-path-to-mydbfile.udb is the full path to the new database of users you have set up.

For an official site, such as a student group or departmental site, the full-path would be

/www/data/cu/yourgroup/yourfile-webacl.udb

For a personal site, on the other hand, you will have to discover the full-path. At the unix command prompt type

echo ~user

and it will return something like the following

/p/rd/user

so the full path name to your file would be

/p/rd/user/yourfile-webacl.udb

Setting Up Your Database of Users

The usernames and passwords in your database should have no connection to UNIs and their passwords. The usernames should start with a string that does not exist in UNIs; for example, 'CU', so that there can be no confusion between these different types of accounts when you restrict access to your data. To create such a database, use your favorite editor to create a plain text file with the following format:

# my comments here next to a pound sign if I want to make a note to myself
username:encrypted-password
nextuser:other-encrypted-password

You can use the command cryptit to get the encrypted form of a password. It will prompt you twice for the password, so that you don't make a typo unbeknownst to you. Then it will produce the encrypted form. For example,

cryptit
Password:
Retype for verification:
ZBg3Hx09JNwuU

In the above exchange, you don't see the password because it is not echoed on the terminal when you type it. The last string of garbage is the encrypted password which you would put into your database like so:

CUscott:ZBg3Hx09JNwuU

Here is a sample password file:

#sample password file
CUbob:ZBg3Hx09JNwuU
CUscott:DVxNx7G8RR4lc
CUcheryl:nN/RKdHYwKOos
CUkim:zccA7sfTs3GJc

You should save this file with the filename ending in webacl.udb. It should be readable by you (the owner) and the group (www). You can check to see theat your database file is properly named and that it has the correct permissions by using the command ls -l on the file. If the permissions are wrong you can use chmod to correct them.

You can put the new database file anywhere you like, although it is probably best to keep it in the same directory as the .htaccess file for ease of administration.

.htaccess Examples

The following example uses the password file example above.

To give all four of our users access, we must explicitly state each user.

AuthType Basic
AuthName "test"
AuthKrbUserType udb
AuthKrbUserFile full-path-to-mydbfile-webacl.udb
allow from all
require user CUbob CUkim CUscott CUcheryl

If you need to allow users with Columbia affiliations access to your documents as well as those without, please follow the directions for allowing both types of users. Remember that you must provide your users with a log out.

« Back to Restricting Access

Restricting Access (Regular Server)
Restricting Access (Both)
Creating a Logout Page