Web Publishing

As a member of the Columbia community, you can publish on the Web, and we encourage you to take advantage of this opportunity.

Regardless of what you publish—a personal website, a site for a course you're teaching, or a site for your group or department—please remember that you are responsible for what you publish. Before you begin, please read and understand the Columbia Copyright Policy.

Creating Websites

  1. Set up your own personal blog (essentially a website with time-based content) at Columbia Blogs.
  2. If you're familiar with HTML and Javascript and would like to build your own site from scratch, you can set up a site in your space associated with your CUIT UNIX account.
  1. You can use CourseWorks to publish your syllabus, assign homework, invite online participation, and perform a variety of other functions.
  2. You can set up a course blog through EdBlogs.
  3. You can use Zoom video conferencing to hold (and record) remote meetings or classes
  1. You may request a group blog (essentially a website, with time-based content) on Columbia Blogs.
  2. If you need a custom design, along with assistance in setting up and maintaining your site, look no further than CUIT's Web and Mobile Apps team, which offers competitive, fee-based Web design, development and maintenance services to the entire University.
  3. If you need a basic site design, CUIT and Public Affairs offer free standard websites with research, administrative, and academic models.
  4. If you are familiar with HTML and Javascript, or just need some Web space, you can request space.
  5. If you are interested in setting up a site for documentation, training materials, meeting notes, or related information, perhaps a wiki is the right tool for you. You may request a wiki at Confluence@Columbia.

Guides

If you are creating these documents for an official site (not in your personal account web space), then your documents should reside on the Columbia's secure Web server somewhere underneath /wwws/data; For example, if your documents reside on the regular server in /www/data/cu/arthistory then your documents on the secure server should reside in /wwws/data/cu/arthistory. The URL is then https://www1.columbia.edu/sec/cu/arthistory/

If you are creating these documents for your personal account web space (~username), you need to make a directory called secure_html in your home directory (not in your public_html directory), to hold your files. The URL is then https://www1.columbia.edu/~username/

The group associated with the directory where you will put your files should be www and the permissions set so that only the owner and group may read. To change the group and set the permissions for your directory you must use the setweb command. This command must be used after you create the directory, and before you put any files in it. So, at the prompt you would type setweb directory-name. Here is an example:

$ pwd
/wwws/data/acis/rad/ 

$mkdir stuff

$ ls -ldg stuff
drwxr-x--- 2 ariel staff 512 Jul 28 15:34 stuff

$ setweb stuff

$ ls -ldg stuff
drwxr-s--- 2 ariel www 512 Jul 28 15:34 stuff

Now Ariel can move files into her directory or create new files to save in that directory. They will all have the correct group associated with them. For all of these files, she should set the permissions so that the owner and group have read permission, but not others.

To restrict access to your documents, you need to create a file with the name .htaccess in the top-level directory of the documents which you wish to protect. In the .htaccess file, you must begin with the following lines:

AuthType Basic
AuthName "test"
AuthKrbUserType type-of-lookup

where "test" is whatever you would like to name your project (in double quotes) and type-of-lookup is either krb or udb, depending on how you want the user id to be checked. To continue your .htaccess file choose your method of access:

  • krb allows Columbia users to log in using their UNIs.
  • udb allows you to create a list of users and passwords (useful if someone without a Columbia affiliation needs access).

Logout Option

When a user logs in on the secure server, the browser typically remembers for a time that the user is logged in with that username and password. This allows the user to navigate the website without having to log in again and again. Typically, the browser forgets this logged-in state when it is closed.

If the person is using a browser at a public terminal or even at a machine that is shared in an office, the user should quit the browser or restart it. However, so that you need not rely on the user remembering to restart the browser, it is a good idea to create a 'logout' option that will cause the browser to clear the user's login state. We highly recommend that you use this option. There is no logout option available for the regular server.

There are two ways to create a logout option.

  • Place a link to the general Columbia logout page
  • Create your own logout page

To use the general Columbia logout page, simply place a link to

https://www1.columbia.edu/pamacea/logout.html

To create your own customized logout page, place a link directing your users to a page in another directory that you have protected with a .htaccess file. This page is the 'Logout' url and it may have any text you like, such as "Thank you for using our service" or any other message that is appropriate. It should be protected by a .htaccess file, with only the following line:

AuthKrbLogout

Environment Variables

Our method for authenticating users via a log in provides the following extra environment variables to your cgi scripts and your server-side include documents, for your convenience:

USER_TYPE -- either krb (indicates a computer account id or a UNI was used to log in) or udb (indicates a name out of a user-maintained database was used to log in

USER_AFFILIATIONS -- list of affiliations and unix groups to which the user belongs

USER_EMAIL -- the e-mail address of the user as listed in our directory

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 email address, this may no longer work. Use USER_EMAIL instead.

If you wish to restrict access to a Web directory on the regular server to a specific list of users, the list of valid users will be contained in your htpasswd file, which is created and modified by the htpasswd program. This file is stored in your directory and maintained by you, so you will need to enter the usernames and passwords yourself. You are the only person that can change passwords and add new users to the file.

The passwords in this file are encrypted using a simple algorithm, so it is important that your htpasswd file should not be publicly readable. At the same time, your htpasswd file must be readable by the web server. Therefore, it is important that you follow these steps when creating your htpasswd file. After you are familiar with the process you can try different directory names and file names.

Create the htpasswd File

Create an empty directory.

$ mkdir ~/passwd

Use the setweb program to put that directory in the www group and make it group readable.

$ setweb ~/passwd

In that directory create a new password file containing your username. If your username is xyz4 you would type $ htpasswd ~/passwd/htpasswd xyz4

Type the password that you will use to access Web documents. Make up a new password: do not use your CUNIX password here.

Additional usernames can be added using the htpasswd program $ htpasswd ~/passwd/htpasswd jkl3

Type the password that jkl3 will use to access Web documents. Tell them to make up a new password: do not use their CUNIX password here.

The htpasswd program will make sure that your password file is not publicly readable.

The htpasswd file was created in the ~/passwd directory so it will be in the www group. You can move it to another directory but we recommend that you leave it there. If your password file is not in the www group then you forgot to run setweb (see above).

If you decide to use separate password files for various web directories we recommend that you put them all in the ~/passwd directory. But it would be easier to create a single password file and use it for all your web directories that need to be restricted.

Create the .htaccess File

Use the echo command to determine the full path to your htpasswd file

$ echo ~/passwd/htpasswd

If your username is xyz4 the system would respond this way

/h/u4/x/xyz4/passwd/htpasswd

Go to the Web directory to which you want to restrict access. If you are going to restrict access to your ~/public_html/private directory, you would type

$ cd ~/public_html/private

Create a file called .htaccess in that directory, bearing in mind the path information obtained earlier (e.g. /h/u4/x/xyz4/passwd/htpasswd). The .htaccess file should contain these directives, at least

AuthType Basic
AuthUserFile /h/u4/x/xyz4/passwd/htpasswd
AuthName "ByPassword"

Require valid-user

The "Require valid-user" directive will permit access to any user in your htpasswd file. Alternatively, you could name all the users that should have access, for example

Require user xyz4
Require user jkl3

Make the .htaccess File World Readable

Using the chmod command, add read access for everyone.

$ chmod a+r .htaccess

Conclusion

Any Web access to a file in your private directory will cause the browser to prompt for a username and password. Since you are the owner of that file, you are the only person that can change passwords and add new users to the file. Use the htpasswd program to modify that file.

$ htpasswd ~/passwd/htpasswd jkl3

You can also include the "satisfy any" directive to allow access by domain name or by password. In that case the web browser would not prompt for a password if the user is in the specified domain:

AuthType Basic
AuthUserFile /h/u4/x/xyz4/passwd/htpasswd
AuthName "ByPassword"

Satisfy any
Order deny,allow
Deny from all
Allow from .columbia.edu
Require valid-user

You can restrict access to a Web directory to a specific list of users. Users will be required to log in when attempting to access documents you place in this directory.

If all of the users that need access to your documents are affiliated with Columbia, you can make use of their UNI.

For users not affiliated with columbia, you must maintain a list of user names and passwords. If you are going to maintain this list and place your files on the regular server, you should follow the instructions for using the regular server. However, placing your files on the secure server will add an extra measure of security. If your users include both columbia and non-columbia users, you may have those with UNI's use that ID system, and for the others, you may maintain your own username and password list. You are required to use the secure server if your users will be using their UNI's.