White dot for spacing only
The Dice Project


webmark.html,v 1.6 2008/03/11 16:07:33 gdutton Exp

(MSc Dissertation) Web Marking Service

This document outlines the Web Marking system.

Structure

The webmark service is an Apache/PHP web service which calls on LaTeX to generate PDF replicas of 'legacy' marking forms, eliminating much of the duplication of information required to mark (currently) an MSc or UG4 Dissertation/Project.

The service defines a specifically configured Apache server, featuring indirect Kerberos authentication. On this runs a set of PHP scripts which perform the bulk of the work of the service.

The webmark website consists of a number of web 'form groups', each of which share configuration for a number of forms. Each form generates one or more PDF paper versions of the typed data. These PDFs are created by filling predesigned LaTeX templates which match the forms required by School and/or College to mark a piece of work. A PHP script calls LaTeX, generates a PDF which allows the user to save, print or optionally (if authenticated) submit to an ITO storage area.

On Fedora Core 5 servers, authentication is currently carried out using the DICE Apache x509/kx509 functionality, utilising the user's Kerberos credentials directly from their DICE PC or through the Informatics Authportal. On FC6 and SL5 this functionality is provided by Cosign. From the authentication mechanism, access rights could be subsequently derived from the user's 'roles', as given by LDAP.

Operation

Using webmark is a three-stage process. Select a specific form to be partially auto-completed from the index page, or simply choose to write a blank form. Once the form has been filled in, clicking preview will produce a downloadable PDF for the user to review the formatted form input. Clicking submit will generate another PDF and, if user permissions allow, send a copy of this to the specified storage location. If submission was successful, the user is notified by a success message, and an email receipt of their submission.

The service was designed to offer no other significant functionality; specifically it was designed to operate statelessly, not relying on any session data. Each of the PHP scripts should have the ability to operate independently of one another. As such, it offers no tracking or dependency checking.

Reconfiguration

In the first instance, the service is defined, and can be reconfigured, by the following:

  1. Server-specific webmark header configuration in the profile
  2. Modifying or creating form (tex or html) data within webmark/data/forms/.
  3. Modifying of creating a form-group's configuration in webmark/data/forms/formtype/config.ini

By default, the service expects to be the primary to have the machine's hostname as its main virtual host. To define a service as 'the' webmark service, simply point the appropriate DNS alias at the machine, then define WEBMARK_HOSTNAME to be webmark (or appropriate alias).

Point 1 above would be expected in the normal operation of the server, and are detailed in Installation/Disaster recovery below, and in the header file itself. Points 2 & 3 would be expected in the course of commissioning a new form type, or changing the behaviour of a specific form.

Point 3 in particular might refer to changes to the auto-completed data which is used by the prefilled forms. This file might require modification if the project databases change in structure, or have to be retrieved from another source. The config.ini file defines separate queries and database connection innormation for each form group, kept deliberately separate to aid in future modification. Simply edit the variable which contains the query string, following the same output pattern as is already defined.

The TeX templates (point 2 above) are processed in the following manner:

  1. A set of field values are populated from the data given to the submit script.
    These are of the form \providecommand{\fieldname}{Field Value}.
    Note that the Field Value is filtered, and can not contain LaTeX commands.
  2. These values are assembled into a master file, along with optionally included files (which define form-field macros and other useful form generation TeX, along with default values for unfilled form fields).
  3. The relevant form template is then selected and included to the master file.
  4. This master file is then passed through pdflatex before being presented to the user as a finished form. The input is filtered such that it should not be possible to create an erroneous LaTeX document, so any errors are handled in a generic manner, requesting the user contact support.

Editing the output is simply a matter of adjusting the TeX templates to suit. Editing the input is a matter of adjusting the form html. POST variables are translated (after security filtering) directly to LaTeX commands.

A sample config.ini file is provided which should give enough detail to create new forms as required.

Installation / Disaster recovery

Webmark is almost completely stateless, and so requires no user data to be restored as such. Installation is relatively straightforward:

  1. Check out the appropriate DICE 'webmark' subversion repository into your proposed Apache server root, for example: For FC5 / apache-component platforms:
    $ svn checkout svn checkout svn+ssh://svn/disk/svn/webmark/branches/apache /disk/webmark/
    
    For FC6 / SL5 / apacheconf platforms:
    $ svn checkout svn checkout svn+ssh://svn/disk/svn/webmark/branches/apacheconf /disk/webmark/
    
    Note that this can be anywhere secure; it will not be holding long-term data unless you set it as the submit location (a very bad idea).
  2. For 'apache' component installations: set the WEBMARK_SERVERROOT definitions to the actual location of /disk/webmark above.
    For 'apacheconf' component installations: set the WEBMARK_DOCROOT and WEBMARK_DATAROOT definitions to /disk/webmark/html and /disk/webmark/data subdirectories above, or as appropriate. You should then run the setup script in the root checkout directory.
  3. [if you are not replacing the webmark machine] define the webmark host to be the DNS name of the machine, or some other alias valid in DNS, e.g.:
    #define WEBMARK_HOST machinename
    
    or
    #define WEBMARK_FULLHOST machinename.inf.ed.ac.uk
    
  4. Set the other appropriate headers:
    #define WEBMARK_DOCROOT         [webmark base path]/html
    #define WEBMARK_DATAROOT        [webmark base path]/data
    #define WEBMARK_SUBMIT		[directory to accept submissions]
    #define WEBMARK_YEAR		[academic year-beginning, e.g. 2008]
    
    (see the webmark header for full details)
  5. Add the #include <dice/options/webmark-server.h> to the profile, somewhere below the WEBMARK_ definitions. You should of course copy any relevant configuration from the old profile.
  6. [if you are replacing the webmark machine] Transfer the DNS alias 'webmark' to the new server. Wait a while for DNS to propagate, or force an update on the new server and the x509 CA machine.
  7. Restart the new server to allow all components to reconfigure themselves, or invoke the following component methods:
    updaterpms run
    file configure
    x509 configure
    cosign configure
    apacheconf configure
    apacheconf start
    


 : Units : Research_and_teaching : Documentation 

Mini Informatics Logo - Link to Main Informatics Page
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh
Spacing Line