If you are a Central Web provider and you wish to use this method, your data should reside on Columbia's secure Web server somewhere underneath /wwws/data; for example, if your data resides on the regular server in /www/data/cu/arthistory then your data on the secure server should reside in /wwws/data/cu/arthistory.
If you are providing data in your home directory, you need to make a directory called secure_html in your home directory, to hold your files.
You should change the group associated with the directory where you will put your data to be www. Then you will want to set the access permissions on this directory and its files so that the owner (you) and the group can read them but no one else can.
See Using the Columbia Secure Web Server for more details about the secure server and publishing data.
You need to create a file with the name .htaccess in the top-level directory of the files which you wish to protect.
In the .htaccess file, you must have the directive
AuthKrbUserType type-of-lookup
where type-of-lookup is either krb, udb, or both, depending on how you want the user id to be checked.
Any time that a computer account id can be used to log in to a restricted service protected by CheeseWhiz, the university network id can also be used. Either may be specified in the htaccess file (see below) with interchangeable results.
If you choose to use the computer account ids/university network ids, unix groups and/or affiliations in the lookup database for authentication; then you should put the line
AuthKrbUserType krb
in your .htaccess file.
AuthKrbUserType udb
in the .htaccess file. You will need additionally to add the line
AuthKrbUserFile full-path-to-my-file-webacl.db
where full-path-to-my-file-webacl.db is the full path to the new database you have set up.
The usernames and passwords in your database should have no connection to computer account ids (cunix ids) or passwords. The usernames should start with a string that does not exist in computer account ids; 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 flat file with the following format:
# my comments here username:encrypted-password:group1 group2 ... groupn nextuser:other-encrypted-password:othergroup1 othergroup2 ...
For example, a sample file might look like
#sample password file ariel1:ZBg3Hx09JNwuU: ariel3:DVxNx7G8RR4lc:websrc staff ariel2:nN/RKdHYwKOos:websrc ariel4zccA7sfTs3GJc:
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: Hs7coyDZoNi8s
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.
This file should be readable only by you. You can check this by using the command ls -l on the file.
If the permissions are wrong you can use chmod to correct them.
Then use the command apache-convertdb to convert this to a database of the format that the Web server will be able to read, for example,
apache-convertdb myflatfile mydbfile-webacl.db
where myflatfile is the name of the text file you created, and mydbfile-webacl.db is the name you will give to the new file. This new filename must end in webacl.db.
Make sure the new file is readable by the Web server www. You can check this by using the ls -l command.
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. The plain text file can be kept there too, although readable only by you, as was mentioned above.
AuthKrbUserType bothin your .htaccess file.
Typically, you might add
require valid-user
to allow any user with a valid user id and password to get in, or you might replace the require line with something more restrictive, such as
require user ariel ben
which allows only the specified users to access the files, or
require group CUNIX_rad CUNIX_sy
which allows only members of the specified groups to access the files, for example.
As we saw above, unix groups must be entered with the prefix 'CUNIX_' in front of the name. Other user affiliations can also be checked; see Affiliations used by CHEESE or CheeseWhiz for a list of these. If you would like to know what affiliations you have attached to your id, you can get the goods by logging in with either your computer account id or your UNI. Don't forget to come back here when you are done to log out.
For more about these standard directives, see Apache's documentation on the <Limit> directive and the require directive.
You would then use the usual line in the <Limit> section of your .htaccess file,
require group my-favorite-group my-next-best-group...
which would require the user to be in one of the named groups, either as a unix group (with CUNIX_ prefixed to the name as you entered it into the list) or a lookup affiliation.
A typical .htaccess file might look like this:
AuthType Basic AuthName "Test CheeseWhiz" AuthKrbUserType both AuthKrbUserFile /stealth/users/ariel/public_html/test/auth/ariel-webacl.db <Limit PUT GET> allow from all require group CUNIX_websrc CUregStudent </Limit>
Note the double quotes around the AuthName; these are required in Apache 1.3 and up.
<include type=hidden name=aclfile value=/full/path/to/my/aclfile>
in your form.
You will almost certainly want to use acl files in any case if you are concerned about access to CGI scripts called by your forms; for more information see Using CGI scripts on the ColumbiaWeb secure server.
You should note that if the USER_TYPE is krb, the REMOTE_USER environment variable will always contain the UNI and not the computer account id. If you have been using REMOTE_USER as a substitute for the e-mail address, this may no longer work. Use USER_EMAIL instead.
If the user is using a browser at a public terminal or even at a machine that is shared in an office, the user should exit the browser or restart it. However, a mechanism for a 'logout' option has also been provided, so that you need not rely on the user restarting the browser. We highly recommend that you use this option. You can place a link directing your users to a page which is the 'Logout' url. This page may have any contents you like; perhaps, 'Thank you for using our service, come again', or any other message you see fit. But it should be protected by an .htaccess file, with the same AuthType and AuthName as the area you want the user to log out from. You will have the same AuthKrbUserType in addition, but after that, the line
AuthKrbLogout
In addition of course you will have the 'require valid-user' directive inside of a <Limit> tag which allows anyone who types a blank password to access the logout page (and hence to clear their password from their browser).
So a logout .htaccess file for the example area above would look like
AuthType Basic AuthName "Test CheeseWhiz" AuthKrbUserType both AuthKrbLogout <Limit PUT GET> allow from all require valid-user </Limit>
The user will be asked by the browser for his or her user id and password. He or she should leave the password blank; the entry will be rejected otherwise. Once the entry is accepted, the browser will store the user id with a blank password, so that if someone else uses the same browser he or she cannot use the cached information to gain unauthorized access to restricted materials.
You will want to inform your users that they must enter a blank password in order to log out; this should be done on the page with the link to the logout url. An example of the whole setup in action is available for your perusal.
~ariel/test/auth/but only once on
~ariel/test/auth/index.html; this has to do with the expansion of the url as directory to the url as index.html below that directory. If you are concerned about speed, you can change references in your documents so that the index.html is explictly given.