You can password protect any pages or sub-pages of the CSE site over which you have control. I should add the caveat that perhaps the phrase "password gating" would be better, since this is not the most secure protection method. If you are very concerned about privacy, the drawbacks of standard htaccess password gating (what I describe below) are:

• Passwords are sent between the broswer and the CSE web server in "plain text", which means someone could potentially go to the trouble of snooping the connection and seeing the password.
• Passwords are often cached in the remote browser. This means the security of your page is at the mercy of who is using the browser and whether or not they are careful to exit it before others have a chance to access it (for instance, in public-access computer areas). This is nothing new, the same concern exists with remote logins. It is more obvious to some people to be careful with a login though. In any given session with a browser, it's not always obvious that if you leave the page, you can go back to it again without re-entering the password.
• htaccess password protection only applies to people accessing your page through a properly-configured web server. If you are trying to protect your data from users *inside* the department, the situation is more complex. There is a suggested workaround below.

That said, using htaccess password protection will keep all but the most determined users (and users on the "inside") away from your data.

So how does one set it up?

Say you (user jsmith) wanted to put a password on documents under the "restricted" subdirectory of your web area:

/cse/htdocs/users/jsmith/restricted

The basic steps are:

• Determine usernames and passwords for your page, and create a password file containing them.
• Create a configuration file local to the

  jsmith/restricted

  directory, that tells the server to check all access requests for a correct username and password.

Create the Password File
First, you need to create a set of username/password pairs that will be used to verify connection attempts to your page. Note that these passwords are chosen by you, and have no relation to the CSE system passwords. In fact, do not use your CSE password, even though it may ease your memorization load. As mentioned earlier, these passwords will be used in different situations than your CSE password -- situations that can expose the password to unintended third parties. It's relatively safe for the password to a few web pages to be compromised, but it's much more potentially damaging to the department as a whole if a user's CSE password is compromised.

Okay, that said... when you create one or more username/password pairs, you store them in a file. We'll call that file .htpasswd, but it doesn't have to be called that. Often, it is recommended that you put the .htpasswd file somewhere outside the web root (in other words, not anywhere under

/cse/htdocs

Use the

htpasswd

	% cd /cse/htdocs/users/jsmith/restricted
	% htpasswd -c .htpasswd username

	% htpasswd .htpasswd username

Create the Configuration File
Now you need to tell the web server that this particular page needs to be protected, that only certain users are allowed, and that they have to know their correct password. This is done in a file called

.htaccess

##############################
AuthType Basic
AuthName "The jsmith Private-access Extravaganza"
AuthUserFile /cse/htdocs/users/jsmith/restricted/.htpasswd
AuthGroupFile /dev/null
Require valid-user

# Since the .htpasswd file is in this directory, make sure nobody outside
# can read it...
#
<FILES .ht*>
order deny,allow
deny from all
</FILES>
##############################

The text on the second line defines a "realm" name. This name will often be presented to the user as part of the login/password box (depending on what browser they're using, of course). You could also conceivably use the same realm name for other protected areas as well. If a user supplies a valid username/password once in a session, then any other attempts to access files in the same realm will be automatically granted. The "valid-user" requirement means that anyone in the .htpasswd file can gain access, as long as they give a valid password. You could further restrict this to just a subset of your password-file users by either creating a group file (see the apache site documentation for details), or by listing the specific users on the Require line.

Make Sure the Server Can See Everything
Now you need to make sure that your files are world-readable. This is "world" in the sense of "everyone with a CSE account", not "everyone in the entire world". The reason you need to do this is so that the web server itself can get at the files:

   % chmod o+x /cse/htdocs/users/jsmith/restricted
   % chmod o+r /cse/htdocs/users/jsmith/restricted/.htpasswd
   % chmod o+r /cse/htdocs/users/jsmith/restricted/.htaccess

"World-Readable" still gives me the willies...
Okay. For some of you, more restriction on the local side may be desired. The situation does get a little tougher if you need to restrict your data both externally and internally. There is a workaround though, and that involves allowing the web server access to your files via the group it runs as, instead of opening up the files to all CSE users. The problem is that you'll need to involve csehelp, since you need superuser access to do this.

The basic idea is that the top-level directory of your restricted hierarchy should *not* be readable or searchable (also known as "executable") to world. This prevents/allows one to cd into or through the directory. But it should be executable to you and the web server. So the top directory needs to be owned by you (so you can get in and do stuff), group-owned by http, and mode 750, or

rwxr-x---

Internal Group Access
Okay, so you want to do like the above, but allow a group of CSE users internal access instead of just you. This gets yet more complex. What you have to do in this case is have an "umbrella" directory that chokes off access to all but the web server and your group, then inside there you create files that are world-read/executable. You protect the directory from outside users with .htpasswd and .htaccess as described above.

The setup for a jsmith directory that was writable and accessibly only by local users in the faculty group would look like this:

  r-xrwx---  http   faculty   /cse/htdocs/users/jsmith/umbrella
  rwxrwsr-x  jsmith faculty   /cse/htdocs/users/jsmith/umbrella/restricted

The restricted directory would be set up as described previously. Files inside there would be owned by jsmith. jsmith would need to make sure they were group-owned by faculty, and the permissions allowed group read/write, and world-read (so the web server can serve them). General users, while theoretically able to read those files due to them having world-read permission, would in fact never be able to get to them since they could not get past the umbrella directory in the first place.

As with the previous setup, you'll need to get csehelp to set up the ownership and permissions of the umbrella directory.