If, after submitting the login form, you are presented with the login screen again, this means either that you mistyped your password or that you are not permitted to access the particular document. If you fail to login in because the password you enter is incorrect more than 5 times in a row, you will be 'blacklisted' from the particular url so that you may no longer retrieve it. If this is due to an honest mistake or because someone else has tried to access the url using your user name, you can call the Help Desk to get removed from the blacklist. There may be a delay of up to 24 hours during the week, or longer over the weekend.
https://www1.columbia.edu/ch/big/acis/rad/cheese/utils/chlogout.html.You can either get rid of all of your tickets or just the current one. Unless there is a compelling reason, you should choose to get rid of all of your tickets.
After you complete the logout process, you should clear the cache of your browser, *especially if you are using a public terminal*, just to be sure that no one can come by later and use the Back key or some other mechanism to see the files that you retrieved.
All documents in a user CHEESE area are located in https://www1.columbia.edu/~username/... where username is the cunix id of the user whose file you wish to retrieve.
CGI scripts under CHEESE are located in https://www1.columbia.edu/ch/big/cgi-bin/
setweb .
This will make www the group owner of all of your directories and files underneath the current directory.
Now you can move all of your files into place. If you need to make new subdirectories under this one, they will have group www automatically. So will your files.
In order to set read permissions properly on your files and directories after you get them into place, go to the directory where you put them, and use the following command:
chmod -R g+r o-rwx .
and it will take away read and write permissions from everyone except you and members of the www group for all files and directories under the current one.
In order to determine whether a given user's ticket is valid for a particular document, CHEESE looks in the same directory for a file with the same name as the document but with a preceding '.'. If it does not find such a file, it looks for a file called '.default' in the same directory. Failing that, it will look in the directory above the current one for a file called '.default', and so on until it looks in the secure data root for such a file. If it fails to find one there, it will deny access.
The first such file that auth finds will determine the access policy of the particular document. A sample file might look as follows:
# this controls document access for our entire tree. allow acis fac staff expire 5 m
Lines beginning with '#' are comments.
Blank lines are ignored.
Data lines consist of fields separated by whitespace.
The first field must be one of the following keywords:
The document access policy files should be readable by www; you can chmod g+r on these files to make sure that they are.
Other than that, you can build your index in the usual way.
<input type=hidden name=docroot value="/zc/cnet/data/ch/big"> <input type=hidden name=webindex value="/zc/cnet/webindex"> <input type=hidden name=urlprefix value="https://www1.cc.columbia.edu/ch/big">
You also need to change the line that defines the indexdir variable so that instead of the value beginning with /usr/local/lib/www/data it begins with /zc/cnet/data/ch/big.
An example is shown below. If the original form looked like this,
<form action="/cgi-bin/aglimpse" method=POST>
<b>Search collection:</b>
<input name=query size=30>
<input type=hidden name=dbname value="Digital Texts: PastMasters">
<input type=hidden name=indexdir
value="/usr/local/lib/www/data/dlc/pm/lib">
<input type=hidden name=urlpath value="/dlc/pm/">
<input type=submit value="search">
<input type=hidden name=whole value="on">
</form>
then the altered form should look like this (changes and additions are in boldface):
<form action="/cgi-bin/aglimpse" method=POST>
<b>Search collection:</b>
<input name=query size=30>
<input type=hidden name=dbname value="Digital Texts: PastMasters">
<input type=hidden name=indexdir
value="/zc/cnet/data/ch/big/dlc/texts/lib">
<input type=hidden name=urlpath value="/dlc/pm/">
<input type=submit value="search">
<input type=hidden name=whole value="on">
<input type=hidden name=docroot value="/zc/cnet/data/ch/big">
<input type=hidden name=webindex value="/zc/cnet/webindex">
<input type=hidden name=urlprefix value="https://www1.cc.columbia.edu/ch/big">
</form>
cd; mkdir private_html
Once you have created this directory, you should be sure that only you and the www group can read any files put there. You must do this before you start putting files or other directories in it. Do this by using the following command to change the group ownership of the directory to www:
cd ~/private_html; setweb .
And after you put your files and directories in place there, use the following command to turn off read/write permissions to everyone but you and the www group:
cd ~/private_html; chmod -R o-rwx .
mkdir ~/private_conf; setweb ~/private_conf
which will set the ownerships correctly.
Now, within this directory, you need to set up the file cheese.cfg with two entries, to tell CHEESE what sort of passwords lookup you want and what sort of affiliations lookup you want.
Here is a sample file:
#This is a sample CHEESE configuration file. Passwords:both Affiliations:both
Instead of 'both' you might use 'local' or 'global' for either the passwords or affiliations lookups.
If you ask for global password lookups, this means that the user, in order to get to one of your documents, must give their cunix id and password.
If you ask for local password lookups, this means that you keep a small file of user names and passwords that is completely independent of the cunix ids; it may (and should) have user names that don't exist on cunix, and passwords that are in no way connected to cunix passwords.
If you ask for both, as in the example file, the user name and password that the user provides will be checked against your local file first and, if not found there, against the cunix databases.
If you ask for global affiliations, the user's affiliations will be retrieved from the lookup database for you. These affiliations are not documented anywhere (sorry about that!) and are probably most useful for central Web providers.
If you ask for local affiliations lookup, the user's affiliations will be retrieved from a local file that you maintain; the affiliations will be entirely arbitrary, according to your needs.
If you ask for both, as in the sample file, the user's affiliations will be looked up first in your local file and then in the lookup database; the total list of affiliations thus obtained will be checked against to see if the user is authorized to retrieve your document.
If you decide to use a method that requires a local password file, the file should look something like this:
#sample password file ariel: tom: dick: harry:
Lines that start with '#' are comments, and blank lines are ignored. The first word in each line is the user name; put a colon (':') after it, and then the encrypted password. To find the encrypted form of a string, you can use the cryptit command; it will prompt you twice for a password (to make sure that you didn't make a typo when entering it) and then output an encrypted form of the password.
If a user wants to change their password, you can help them to automate the process somewhat by setting up a change of password form for them. (More documentation on this feature later.)
If you use an access method that requires a local affiliations file, the file should look something like this:
#sample affiliations file ariel:all admin cool tom:admin boring dick:boring harry:boring
Lines that start with '#' are comments, and blank lines are ignored. The first work in each line is the user name, the same as in the local password file or the cunix login, depending on how you are looking up passwords. Follow this with a colon (':'), and then put a list of the affiliations you want the user to belong to.
A user can belong to more than one affiliation, as you see in the file above. Just put spaces between them in the list.
cd ~/private_conf; chmod -R 750 .
which will set the ownerships and permissions of all of your configuration files correctly.
Since you are putting up html files that you don't want everyone to be able to read indiscriminately, you want to make sure that you, the owner, and the www group which includes the web server, have access to the files, but no one else. In order to do this, you can use the following command:
cd ~/private_html; chmod -R g+r o-rwx .
This will take away read and write permissions from everyone except you and members of the www group.
You should have run setweb in the private_html directory and in the private_conf directory when you created them, and before you put any files or directories in place underneath these directories. If you put directories and files in place, and ran setweb afterwards, the directories and files already in those directories will have the wrong group ownership. You can check this by using the command
ls -lag ~/private_conf ~/private_html
A 'good' list might look like the following:
aloha% ls -lag ~/private_conf ~/private_html /sh/rd/ariel/private_conf: total 8 drwxr-x--- 2 ariel www 512 Oct 11 12:53 . drwxr-xr-x 46 ariel rad 4096 Oct 25 16:47 .. -rwxr-x--- 1 ariel www 22 Oct 11 12:53 chaffils -rwxr-x--- 1 ariel www 61 Oct 9 10:49 cheese.cfg -rwxr-x--- 1 ariel www 19 Oct 8 17:08 chpasswds /sh/rd/ariel/private_html: total 16 drwxr-x--- 3 ariel www 512 Oct 25 12:48 . drwxr-xr-x 46 ariel rad 4096 Oct 25 16:47 .. -rwxr-x--- 1 ariel www 24 Oct 11 12:52 .default -rwxr-x--- 1 ariel www 1753 Oct 11 13:22 cheeseadmin.html -rwxr-x--- 1 ariel www 487 Oct 14 12:26 chlogout.html -rwxr-x--- 1 ariel www 1034 Oct 14 12:45 chpasswd.html -rwxr-x--- 1 ariel www 671 Oct 14 12:54 encryptpwd.html drwxr-x--- 4 ariel www 512 Oct 25 16:05 other
You see the name 'www' after the user name in every file except those named '..'.
If you see some other name there, eg. a lit like this:
/sh/rd/ariel/private_html: total 16 drwxr-x--- 3 ariel rad 512 Oct 25 12:48 . drwxr-xr-x 46 ariel rad 4096 Oct 25 16:47 .. -rwxr-x--- 1 ariel rad 24 Oct 11 12:52 .default -rwxr-x--- 1 ariel rad 1753 Oct 11 13:22 cheeseadmin.html -rwxr-x--- 1 ariel rad 487 Oct 14 12:26 chlogout.html -rwxr-x--- 1 ariel rad 1034 Oct 14 12:45 chpasswd.html -rwxr-x--- 1 ariel rad 671 Oct 14 12:54 encryptpwd.html drwxr-x--- 4 ariel rad 512 Oct 25 16:05 otherthe the group ownership is wrong, and you will have to correct it. You can correct the ownership of the subdirectories by running setweb on them, but the files will have to be copied out and then copied back in to the directory in order to change the group; you cannot run setweb on a file. You cannot use the mv command to accomplish this; the group ownership will still be wrong. You must use cp.
CHEESE recognizes the following tags and will rewrite the associated urls within them: A AREA FORM IMG FRAME BODY.
If you want to prevent CHEESE from editing a url in your document, for example, a pointer to a document outside of the secure data area, you can add the word 'NOCHEESE' to the beginning of the path.
For example, if I wanted to allow the user to return to my home page I would code the following url:
http://www.columbia.edu/NOCHEESE/~ariel/
If you want to use NOCHEESE on a relative url, add it right at the beginning:
"NOCHEESE/images/censored.gif"
but if you want to use it with a relative url that starts at the document root, for example, "/cu/libraries/index.html", put a leading slash before it, like this:
"/NOCHEESE/cu/libraries/index.html"
The CHEESE package will be happiest if there are no html syntax errors, at least as regards href tags, so please do check these portions of your documents carefully.
cd ~/private_html/lib
You need to make this directory readable by the Web server, but not by the world. To do this, use the following commands:
setweb .
Type
echo ~/private_html/path-to-the-dir-I-want-to-index
and note the result. Now type
glimpseindex -o -H . result-from-last-command
and you should see that the index is being built. (You may have to specify the path to glimpseindex, i.e. /usr/local/bin/glimpseindex.)
Make sure the files are all readable by the Web server but not by the world, by using the following command:
chmod 750 . .glimpse*
<input type=hidden name=urlprefix value="https://www1.cc.columbia.edu/ch/big">
For the variable urlpath you should put a leading '/', followed by '~' and your login id, and then the rest of the path to the area you indexed (or the subset of it you want to search), *excluding* the 'private_html' string.
For example, if I had indexed ~ariel/private_html/other, I might set it as follows:
<input type=hidden name=urlpath value="/~ariel/other/">
and if I wanted to search for files in other/coolstuff, I would set it instead to
<input type=hidden name=urlpath value="/~ariel/other/coolstuff/">
You will need to set the variable indexdir so that it has the value you see when you type
echo ~/private_html/path-to-where-you-put-the-index
e.g., if I put the index in ~ariel/private_html/other/lib then I should set the variable as follows:
<input type=hidden name=indexdir value="/sh/rd/ariel/private_html/other/lib">
The rest of your form should follow the rules for using Glimpse in the usual way.
#global configuration file for the CHEESE package # we are on one partition now! big:/zc/cnet/data/globalch/config
We run one CHEESE instance, called 'big', as you can see from the global config file. Its configuration file sits in /zc/cnet/data/globalch/config, and it contains
#CHEESE per-instance configuration file #instance: both DirectoryIndex:index.html ScriptAlias:/cgi-bin/ ScriptDir:/usr/local/lib/www-cheese/cgi-bin SecureDocRoot:/amd/zivijo/zc/cnet/data/globalch/data Passwords:both Affiliations:both
From this you can see that the secure document area for CHEESE is in /zc/cnet/data/globalch/data, and the cgi scripts live in /usr/local/lib/www-cheese/cgi-bin on our secure web server. User names and passwords are checked, first against a local password file and then against the cunix databases. Affiliations are likewise looked up first in a local file and then from the lookup database.
big: [Tue Oct 22 12:52:34 1996] demo CU27Kj4BEcK9yysFslLAXsbJ2@No 128.59.39.149 GET /amd/zivijo/zc/cnet/data/globalch/data/acis/rad/cheese/webcheese.gif [ref https://xxx.columbia.edu:443/ch/chlogin] [client Mozilla/3.0 (X11; U; SunOS 4.1.3_U1 sun4c)]The first entry is the name of the CHEESE instance. We only have one, so this name should always be the same, i.e. 'big'.
Next is the date and time; then the user name, followed by their CHEESE ticket, and their IP address. Finally, the method of retrieval (GET or POST), the url, the url they came from, and their browser type.
The CHEESE error log keeps all errors from cgi scripts run under CHEESE. It logs all successful logins, all failed logins and reasons for the failure, and various other failures.
chdbdeluser chfailures.db blacklist your-user-name
Of course, you will need to have write access to the database to run this command.
After this, you should be able to use the form as described in the previous section.