Authentication

The EvalSuite administration system handles most user authentication. Each user (taker or subject) has an account with a unique user ID and passcode. Individual accounts may be either 'active' or 'inactive'. Users enter their passcodes to access the system and submit forms. Unique ID codes are used to identify individuals in data, reference, and access control files.

EvalCGI also supports single use, temporary passcodes ('tmp codes'). These codes take the form 'tmp99999' where 'tmp' is followed by a unique, usually random number. These codes are useful when there is no formal relationship with takers (ie, they do not have accounts) — a customer survey for example.

Authorization

Authorization is based on user IDs and accounts. ID codes may appear in access control lists (ACL files) or as part of an access control specification (access spec).

ACL files are just lists of user IDs, one per line. Additional information, such as user names, may appear after each code, set off by a space or tab. ACL files may be either local (in the same directory with the forms) or global (shared across all directories). Global ACL files are stored in a central administrative area (typically admindata/lists/).

An access spec may contain a mixture of ACL file names and user IDs, combined with plus '+' and minus '-' characters. The only rule is that all the '+' items must come before any '-' items. In these examples, class05 and class06 are ACL file names while students 1-3 are individual ID codes:

class05+class06-student1
student1+student2+student3

The first example creates a combined list for the classes of 05 and 06 and then removes student 1. The second example creates a list containing three students. Notice that there is no longer a need to create an ACL file for small groupings.

Security Levels

The system grants access at one of five security levels based on the user's authorization. At the lowest level (1) a form is open to the public, without requiring authentication. Form level access (2) takes precedence over the higher levels when the user is authorized as a taker for the form. This allows admin and super users the abiltiy to submit forms as normal users when the need arises. Directory access (3) generally defaults to any valid user (represented by a '*'). This is different from public, which does not check the user's credentials. Admin access (4) enables the form utilities (indicated by ) for a directory and the forms it contains. Superusers have admin access (5) to all forms in all directories at all times.