Frequently Asked Questions

1. What advanced web programming is allowed?

2. Do you support PHP?

We do not currently offer a PHP scripting service on this server. If you need PHP for your work please see NSMS who do provide this as a paid for service.

3. What are web access log files?

You can find out what information is available to web servers about you and your system by clicking on this link

Web Client Report

Information collected in web logs is purely for system related reasons. No specific details of an individual's use of computer systems are not made publically available. However, some server owners do allow third parties access to this information. OUCS has no control over this practice.

The OUCS servers

All the OUCS web servers record information on which files are accessed, when and by whom. This last item consists of the IP name and number of the computer you are using to access the web, together with your user name on that system (if available). IP naming schemes used for computers can allow an individual users identity to be determined.

Other Colleges and Departments of the University also maintain log files. The University IT Committee recommends that these log files are not made available in a form to identify individual users.

4. How do you restrict access to web pages?

It is sometimes necessary to restrict access to part or all of your website because subsections may still be in development or because you only want people using machines with an Oxford IP address seeing your pages. You may want to restrict access to specific users by setting usernames and passwords if you are running a specific course for instance. All these scenarios can be catered for, by following the instructions below.

Restricting access by IP name or address

Every browser accessing the web has an IP (Internet Protocol) name (e.g. (rabbit.oucs.ox.ac.uk) and a number (e.g. 163 1.32.180). Both can be used to restrict access to your pages. It is important to realise that you protect a directory and its subdirectories, not individual pages. To do this you have to create a file called .htaccess which contains an access control list (ACL). This file should be placed in the directory which you wish to protect.

For instance to protect a subdirectory called 'papers' so that it can only be accessed by machines in the Oxford domain you need to add the .htaccess file to that subdirectory. It should contain the following information:

 
	 Order deny,allow 
	 deny from all 
	 allow from .ox.ac.uk 
	 

This works in two steps. First it prevents access for anyone but then allows access to the directory to machines in the oxford domain. You can further refine this statement by changing the Allow from line to read:

Allow from oucs.ox.ac.uk

Only machines visiting from the oucs.ox.ac.uk domain will be allowed to see the directory pages. You can specify more domains by adding further 'allow from' statements to the file. Instead of using the IP name you could use the IP number to get the same result.

5. What about restricting access by username/password?

It is also possible to protect Web directories by username/password combinations. In order to set this up you should follow these steps if you using the OUCS web server (if you are using a different server contact that system's sysadmin):

1. Log in to the Linux system linux.ox.ac.uk using your Oxford username and password
2. Create a file containing usernames and encrypted passwords:

   % htpasswd [-c] passwordfile username

   For example,

   % htpasswd -c /web/users/$USER/cgi/myusers.passwd fred
   Adding user fred
   New password: rubbish (not echoed)
   Re-type new password: rubbish (not echoed)
   

   The file used to store the passwords should not be in the accessible document tree; the cgi directory is a good location (on linux.ox.ac.uk this can be accessed as /web/users/$USER/cgi).

   The -c flag is only needed the first time that the command is used.

   You will be prompted twice for each user's password. You will need to use the htpasswd command for each user you want to add.

3. Make sure that the file which holds the passwords is world-readable. For example:
   % chmod a+r /web/users/$USER/cgi/myusers.passwd

4. The commands to activate the password file are placed in the .htaccess file. As before, this file needs to be placed in the directory where access restriction is to start. For example:

   AuthType Basic
   AuthName my-private-webpages
   AuthUserFile /web/users/aragog.oucs.ox.ac.uk/6/e/fred/cgi/myusers.passwd
   require valid-user
   

   AuthName can be anything meaningful to the people that need to supply a username and password (note that a value is required). If the name contains spaces, it must be given in quotes. Using the above example, when the username is requested the browser will display "Please enter username for my-private-webpages at users.ox.ac.uk"
   AuthUserFile is the location of the file you created in step [1]. This file is actually held on the web server. Therefore you need to give it a path name which is meaningful to the web server:

   1. Type webhome to obtain the path of your home filestore on the web server. For example:

      webhome
      /web/users/aragog.oucs.ox.ac.uk/6/e/fred

   2. The path to your cgi directory is then the value returned by "webhome" and with "cgi" appended:

      /web/users/aragog.oucs.ox.ac.uk/6/e/fred/cgi

   3. The full pathname then becomes:

      /web/users/aragog.oucs.ox.ac.uk/6/e/fred/cgi/myusers.passwd

5. Make sure that .htaccess has got world read access:
   % chmod a+r .htaccess
6. If you want to authenticate by both username/password and client host address, you can use the Satisfy directive in .htaccess to specify whether access is allowed if either test is passed, or if both must be passed (the default).

6. Making a custom error page and redirect

In the "public_html" folder on your OUCS webspace, create a folder called "error"

In this folder, create a new html file, and put in the META tag to redirect to the new URL, e.g.:

<html>
<head>
<META http-equiv="refresh" content="0;url=http://www.my-new-site.com/">
</head>
<body>
This site has moved. If you do not get redirected to our new site, click <a href="http://www.my-new-site.com">here</a>.
</body>
</html>

Save this file as "error404.html" in the "error" folder under "public_html"

Go back up to the "public_html" folder, and create a file named .htaccess, with the following line in it:

ErrorDocument 404 /~USERNAME/error/error404.html

This redirects the browser to the error page you created above, which in turns redirects the browser to your new site. You have to include /~USERNAME (which is your Oxford username) because the .htaccess file needs absolute paths, and the Oxford username is part of this.

Internet Explorer by default displays "Friendly HTTP Error Messages" if the content of your custom error message is less than 512 bytes. So, in the example above you must make sure the page size is greater than 512 bytes. One way would be to add a suitably sized graphic.

7. How can I set up a feedback form?

You will need to create a form and link to a CGI script which will process the form for you. The script will also validate your form before allowing it to be sent to your email account. This script is located at:

http://users.ox.ac.uk/cgi-bin/FormMail.pl

and is available to all web site owners who have an Oxford University email address.

A short tutorial on using this script in a form is provided in the HTML tutorial.

8. What are server side includes (SSI)?

Server side includes are a special type of HTML comment that tells the web server to dynamically generate data and place it in a web page. You can use SSIs on your OUCS web site by naming your files as ' .shtml'. A general tutorial on SSI is available at: http://www.webreference.com/programming/ssi/intro/

9. What is CGI?

The Common Gateway Interface or 'CGI' technology is a well established method for web site interactivity. It is not a programming language itself but a standard method to allow external programs to run on a web server. The external programs can be written in many languages, but the most common one is Perl. OUCS recommends the use of 'Safe Perl' to build CGI programs. More information on the Perl language can be found on the Perl web site: http://www.perl.com

10. Can I write my own CGI programs?

Yes you can. However, we only allow the use of the 'Safe Perl' language to build CGI programs. More information on the Perl language can be found on the Perl web site: http://www.perl.com

11. Do you have any generic Perl scripts available?

Yes, some useful but poorly documented examples are available here: Generic Perl Scripts.

12. Sending email from your CGI script

A secured subroutine is available which allows the sending of mail from a CGI program. The syntax is: 

    mail(RECIPIENT, SUBJECT, CONTENTS);

For example, 

    mail('foo@bar.baz', 'Test mail', "Hello world\n")

        or oops("mail failed");

Note that @ interpolates an array when used in double quotes ("") (unlike in perl4 which tried to guess whether you wanted to interpolate or have a raw @ in there). If you want to hard-wire an email address with an @ in it then either use single quotes or prefix the @ with a backslash ("$user\@wherever"). Note also that you gather the whole message together into one string to pass as the third argument.

Email sent in this way will have a sender address of your own University email address. 

13. Writing your own Safe Perl.

Only a restricted set of the Perl language is available: usage of unsafe features (even within eval statements) are trapped and the program is not run. There are many Perl operators not available to the CGI directory in which your program is run. These include the operators that could affect the operating system. The following list is not exhaustive but includes the most common excluded operators:

• system, `backticks`, exec, fork, syscall, signal handlers, pipes (including open(FOO, "|bar") and open(FOO, "bar|")) 
• network access (socket, bind, connect, ...) 
• File munging (rename, link, opendir, chown, ...) 
• System V IPC (shared memory, message queues, semaphores) 
• File tests (-r, -w, -l, ...) 
• Calling perl on other files (require, use, do 'file')

Opening files for reading/writing is restricted. The "open" command is subject to the following restrictions: 

• Files opened for reading must be owned by the user. Your CGI program is run with a current directory of ~/cgi/. It is strongly recommended that you use relative pathnames (for example, "../public_html/foo").
• Files opened for writing must be opened by using a filename containing no "/" characters. The filename is taken to live in the directory ~/cgi/out and the file must already exist at the time the open is performed. It can be a symbolic link if desired.

Once you have written and debugged your CGI program, put it in ~/cgi/bin (creating that directory if necessary). There is no need to include a leading "#!" line, nor will one be honoured if you do. Supposing that your username is quux and your program is called foo, the URL to run your program is

http://users.ox.ac.uk/cgi-bin/safeperl/quux/foo

When the web server runs your program it will run it with the privileges of your Oxford account.

Any use of a masked operator in your Perl program will trigger a compile time error (which your browser will display) and the program will not run at all. A "masked operator" is an operator which is restricted but which, unlike "open", is not aliased to a secure sanitised version. The error message will be something like opname trapped by operation mask at line ... where opname is replaced by the name of the offending operator.

Please be aware that, even with the restrictions on what your program can do, it is possible that someone out on the web will be able to persuade it do something you weren't expecting. Even with the file limitations, for example, your program may have a bug which lets someone see the contents of any file you own. You are responsible for the CGI programs you write and you must ensure that your CGI programs do not contravene OUCS rules.

Sorting lists

For sorting lists, the perl built in sort operator is masked (since inconsistent comparison subroutines can cause the underlying C library qsort function to core dump). Two functions are provided for sorting lists in the two most common collating sequences: ASCII and numeric. To sort an array @unsorted into increasing ASCII order use 

    @sorted = sort_ascii(@unsorted);

To sort into increasing numerical order use 

    @sorted = sort_numeric(@unsorted);

If you want a decreasing order, then just use the standard Perl reverse operator on the resulting array.

Common problems

• Every CGI script must output at least one header line. If your program generates output, it needs a Content-type line indicating what kind of document (MIME type) it is producing. If your script outputs an HTML page, the correct format is: Content-type: text/html

If it is raw text then

Content-type: text/plain

14. Re-directing to a different site

If you have moved your site from users hosting to a different one either inside or outside of the university you will probably want to re-direct your site visitors to the new location. This is easy to do by:

1. create a .htaccess file using a text editor
2. Type in the following code changing myusername to your username and replace www.my-new-site.com with the real location of your site:

   Redirect /~myusername http://www.my-new-site.com/

3. Save and upload to your users webspace. Visitors to your users web space will now automatically be re-directed to the new location.