In this section we have grouped together a series of frequently asked questions regarding web sites on the personal pages web server. If you cannot find the answer to your question here, please send your question to us via the Help Pages and Form.
1. What advanced web programming is allowed?
There are many restrictions governing the use of the personal pages web server because of security issues. The two activities the web server will allow are:
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?
During your travel around the Internet, you will visit many different servers around the world and, unknowingly, leave a digital trail of your surfing. This is because web servers collect and log information about you and your web client system. There are valid reasons to keep such logs including:
- Help to track security breaches
- Counting how often documents are accessed
- Recording types of browsers being used
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. IT Services has no control over this practice.
The IT Services servers
All the IT Services 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 IT Services web server (if you are using a different server contact that system's sysadmin):
Log in to the Linux system
linux.ox.ac.ukusing your Oxford username and password
Create a file containing usernames and encrypted passwords:
% htpasswd [-c] passwordfile username
% 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.ukthis can be accessed as
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
htpasswdcommand for each user you want to add.
Make sure that the file which holds the passwords is world-readable. For example:
% chmod a+r /web/users/$USER/cgi/myusers.passwd
The commands to activate the password file are placed in the
.htaccessfile. 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 . 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:
webhometo obtain the path of your home filestore on the web server. For example:
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
The full pathname then becomes:/web/users/aragog.oucs.ox.ac.uk/6/e/fred/cgi/myusers.passwd
Make sure that
.htaccesshas got world read access:% chmod a+r .htaccess
If you want to authenticate by both username/password and client host address, you can use the Satisfy directive in
.htaccessto 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 IT Services 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.:
<META http-equiv="refresh" content="0;url=http://www.my-new-site.com/">
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>.
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:
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 IT Services 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. IT Services 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?
11. Do you have any generic Perl scripts available?
Yes, some useful but poorly documented examples are available as a downloadable zip file. This contains:
11. 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);
mail('email@example.com', 'Test mail', "Hello world\n")
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.
12. 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, "
- 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
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 IT Services rules.
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.
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:
If it is raw text then
- The final header output (even if it is only Content-type:) must be followed by two pairs of <CR>/<LF> or, although less correct, two line feeds (ascii 10 decimal). This means there must be a blank line after the last header line.
13. 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:
.htaccessfile using a text editor
Type in the following code changing
myusernameto your username and replace
www.my-new-site.comwith the real location of your site:
Redirect /~myusername http://www.my-new-site.com/
- Save and upload to your users webspace. Visitors to your users web space will now automatically be re-directed to the new location.