How to use the personal web pages service

The guides below explain the various steps of publishing web pages and scripts using our personal web pages service.

If you are new to writing web pages, or coding languages such as HTML; CSS or Perl then you might benefit from one or more of our web development courses. These last from 1 hour lunchtime sessions to courses spread over several weeks. Current courses can be found on our IT Skills site. We also publish a basic web and HTML tutorial.

All web pages at Oxford, whether personal, departmental or college, should conform to the Rules for Oxford University Websites.

Expand All

  1. View settings for your Linux shell account and select Activate Shell Account. If the activation option is not available then you have already done this or you are not entitled to use this feature
  2. View settings for your Personal web space and select Activate Web Space. This can take up to 15 minutes to complete, after which you will see details of your web space and settings
  1. Make sure that you have an SFTP client installed. See our How to connect using SSH / SFTP guide for further information
  2. Use your SFTP client to open a connection with the following details:
    Field Value
    Host or server name linux.ox.ac.uk
    Port 22 (select the TCP protocol if required)
    Username Your Oxford username in the form abcd1234
    Password Your Oxford SSO password
  3. Upload your content files (html, css, javascript, htaccess and other files) to the public_html folder, and any SafePerl scripts to the cgi folder

The home page of your web site should be called index.html and this should be placed in the public_html directory. If you do not have this file in your folder, the server will return a list of all the files in that directory.

If your account was created before 2016 and you cannot see the public_html or cgi folders then use the makeweblinks command to create the folders.

Note: Users uploading files using clients that do not follow symlinks can determine the full path to their webspace by SSH'ing into linux.ox.ac.uk and running the command "realpath ~/public_html".

  1. Access your personal web pages at http://users.ox.ac.uk/~abcd1234, where abcd1234 is your Oxford username
  2. This URL corresponds to the index.html file if you have published one. If index.html does not exist, the server will return a list of all files in your public_html directory
  3. Other files can be accessed using similar URLs, for example http://users.ox.ac.uk/~abcd1234/maths/geometry.html will retrieve the geometry.html file in the public_html/maths folder
  1. Check that your HTML pages are valid using a tool such as the W3C HTML validator
  2. Check your CSS using a tool such as the W3C CSS validator
  3. Check your page accessibility using a tool such as WAVE
  4. Details of further conditions that you need to meet, including legal statements, copyright, data privacy and accessibility are available in the Rules for Oxford University Websites
  1. View settings for your personal web space
  2. Set the option "Include me in personal pages index" to Yes
  3. Select Save changes
  1. View settings for your personal web space
  2. Select the type of web count report you would like and provide an email address (yours) for these to be sent to weekly
  3. Select Save changes

The personal web pages service supports Server Side Includes and SafePerl CGI scripts.

Security considerations for a multi-user web server like this mean that more powerful features such as full Perl, PHP or Python are not available. Please see our Oxford Mosaic or Comprehensive Web Hosting services if you need more advanced features.

Restrict access to specific computers

  1. Use SSH to login to linux.ox.ac.uk, then run the following commands (type and press Enter after each line):
    cd public_html
    pico .htaccess
  2. In the pico editor, type the following lines as shown, then press Ctrl + X to save the file and exit

    Order deny,allow
    deny from all
    allow from pc1.maths.ox.ac.uk
    allow from 163.1.136.72
    allow from .ox.ac.uk
    
  3. Now run two more commands to make sure the file is active, and logout:

    chmod 0755 .htaccess
    exit

Further details

The example .htaccess file above works by setting a default policy of denying access, and then allowing access from hostname pc1.maths.ox.ac.uk, any requests coming from IP address 163.1.136.72 or any computers registered in the .ox.ac.uk DNS domain. You will need to change these lines to specify the rules that you need.

An .htaccess file controls access to all other files in the same directory, and access to any subfolders and their files.

 
 

Restrict access to specific people

  1. Use SSH to login to linux.ox.ac.uk, then run the following commands to create user "fred" and make this information usable by the web server:
    htpasswd -c $HOME/cgi/htpasswd fred
    chmod 0755 $HOME/cgi/htpasswd
    

    You will need to enter and confirm a password for "fred" (the password won't be displayed on screen, and you will need to press Enter after typing it each time). Omit the "-c" part of the command if you are adding further users

  2. Make this file readable and check its location on the web server:
    chmod 0755 $HOME/cgi/htpasswd
    webhome
    
  3. Edit your .htaccess file to require user login:
    cd public_html
    pico .htaccess
    
  4. In the pico editor, type the following lines as shown, then press Ctrl + X to save the file and exit. Note that the value for AuthUserFile is the result of the webhome command, followed by the name of the file you created with htpasswd earlier (cgi/htpasswd
    AuthType Basic
    AuthName my-private-webpages
    AuthUserFile /web/users/aragog.oucs.ox.ac.uk/6/e/fred/cgi/htpasswd
    require valid-user
    

Further details

You can combine host and user restrictions in your .htaccess file. By default both sets of conditions must be met, but you can use the Satisfy directive to change this

 
  1. Create an HTML file called 404.html containing your custom error page. You can use a META tag to redirect users to another location after a set delay, for example:
    <html>
    <head>
    <META http-equiv="refresh" content="5;url=http://users.ox.ac.uk/~abcd1234/">
    </head>
    <body>
    This page does not exist. You will shortly be redirected to my <a href="http://users.ox.ac.uk/~abcd1234/">home page</a>.
    </body>
    </html>
    
  2. Upload this file to your public_html files
  3. Use SSH to login to linux.ox.ac.uk, then run the following commands (type and press Enter after each line):
    cd public_html
    pico .htaccess
  4. In the pico editor, type the following lines as shown, then press Ctrl + X to save the file and exit

    ErrorDocument 404 /~abcd1234/error/error404.html
    

    (Remember to change abcd1234 to your Oxford username)

  5. Now run two more commands to make sure the file is active, and logout:

    chmod 0755 .htaccess
    exit

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 giving your files a .shtml extension.

For more information on using SSI directives read the Apache httpd tutorial Introduction to Server Side Includes.

  1. Write your script in Perl, which includes extensive support for Common Gateway Interface (CGI)
  2. Upload your script to the cgi/bin directory of your account and run the command chmod 0755 myscript.pl to enable it
  3. The URL for a script saved as myscript by user abcd1234 will be http://users.ox.ac.uk/cgi-bin/safeperl/abcd1234/myscipt

For more information on writing CGI scripts in Perl, and some examples, try these links:

About Safe Perl

Safe Perl is configured to provide a more secure way of running Perl CGI scripts in a multiuser environment. You do not need to include the usual "#!/usr/bin/perl" line in your script as it will always be executed with Safe Perl.

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. The following list of restricted operators is not exhaustive but includes the most common cases:

  • system, backticks (``), exec, fork, syscall, signal handlers, pipes
  • 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: 

  • 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 abcd1234 and your program is called myscript, the URL to run your program is

http://users.ox.ac.uk/cgi-bin/safeperl/abcd1234/myscript

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 and the program will not run at all. A "masked operator" is an operator which is restricted but, unlike "open", is not aliased to a sanitised version. The error message will be something like "opname trapped by operation mask at line ...".

Please be aware that it is possible that someone out on the web will be able to persuade your script do something you weren't expecting, even with the above restrictions. 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.

Sorting lists

The perl built in sort operator is masked for security reasons. 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.

Required output

Every CGI script must output at least one header line. If your program generates body output, it must include a Content-type header 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

The header output must be followed by two pairs of <CR><LF>. This means there must be a blank line after the last header line.

Sending email

Our Safe Perl implementation includes a convenience function for sending email. The syntax is: 

mail(RECIPIENT, SUBJECT, CONTENTS);

For example, 

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

You will need to enclose the recipient email address in single quotes, or escape the @ if you use double quotes.

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

 

Site redirection sends all visitors to a URL of your choice. This is particularly helpful if you have moved your site to new hosting arrangements as you redirect anyone using your old site address to your new site.

  1. Use SSH to login to linux.ox.ac.uk, then run the following commands (type and press Enter after each line):
    cd public_html
    pico .htaccess
  2. In the pico editor, type the following lines as shown, then press Ctrl + X to save the file and exit

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

    (Remember to change abcd1234 to your Oxford username, and enter your new site URL)

  3. Now run two more commands to make sure the file is active, and logout:

    chmod 0755 .htaccess
    exit

Method 1: Check your other repositories

If you write your web pages using a web editor or other app and then upload them to the server, then you probably have a copy of all your files on the computer you write them on. Check in your web editing app and the folder locations that you normally use for saving documents.

Method 2: Google Cache

Google search retains a recent copy of web pages that it has indexed. To rescue a page via Google:

  1. Use Google to search for the exact page URL in the format users.ox.ac.uk/~abcd1234/lost_page.html
  2. Select the vertical ellipses menu  next to the relevant search result and then select Cached in the bottom-right of the information panel to display Google's most recent snapshot of your page
  3. If no relevant results are listed, or there isn't a Cached button in the information panel then Google has not retained a snapshot of your page

Method 3: Internet Archive

The Wayback Machine Internet Archive takes periodic snapshots of internet content, and may have a copy of your lost page. To rescue a page via the Internet Archive:

  1. Visit the Wayback Machine Internet Archive and search for the URL of the lost page
  2. If archived copies of the page are available then a calendar will be displayed with coloured dots marking the dates when a snapshot was taken. Select one of the marked dates and select a snapshot time to view that version of the page

Method 4: Data recovery service

Pages lost from the personal web pages service that were more than 1 day old and deleted within the last 30 days can normally be recovered. Check our data recovery service for full details.

Get support


If you cannot find the solution you need here then we have other ways to get IT support

Get IT support