I have written before about the practice of using environment variables to identify authenticated users in our school intranet. Now, finally I have come across an open-source package that uses this method, too! I have installed DokuWiki on our internal server for a collaborative project our diversity club students are starting on San Francisco neighborhoods. This will replace our old UseModWiki that we have had in place for three years.

DokuWiki automatically picks up the $_SERVER['REMOTE_USER'] environment variable, which is set on our IIS server for protected directories. Right out of the box, we get a wiki script that can stay private within our network and automatically identify the authors of all of the wiki edits.

Two small edits were immediately helpful. The first was to remove the domain from the userid, so that it would be shorter and easier to read. The second was to insert a database query against Blackbaud to show the real name of the currently logged in user. The second edit may not ultimately prove that useful, as the userid seems to be used throughout the script and the real name only sparingly.

Interestingly, DokuWiki tracks the current user by setting the REMOTE_USER environment variable if the server folder does not require authentication and DokuWiki is set to use internal authentication instead. For example, if you turn access control on and then log in, DokuWiki sets the environment variable to the new userid. Most programs use a cookie for this purpose.

I was hoping to give everyone editing privileges to the entire wiki, but it is likely that the diversity club will want to maintain editorial control over the content that it is currently working hard to assemble. Toward this end, I have enabled access control lists, but this stops the script from using REMOTE_USER by default, in order to require login first. Too bad! If I want to use access control lists, I will have to modify this script in the same fashion I have modifed the others, pre-empting the login form by capturing REMOTE_USER and creating the logged in state before the script checks for that.

Look for references to REMOTE_USER in /inc/common.php to find examples of its use in DokuWiki. This is where DokuWiki first determines user identity and invokes an authentication process if necessary.

I rewrote our voting script to be consistent with new programming skills learned in the last two years. The script now uses mySQL instead of a flat text file, builds the input form dynamically instead of using a static HTML file, and provides live results to admins. I provided a way to dynamically select among different voting methods.

The script currently supports two: plurality and approval. Plurality is conventional voting: each voter gets one vote per office. Approval voting permits the voter to cast as many votes as desired. I may build other, more complex voting schemes in the future, especially to provide instant-runoff capability. For example, preference voting permits voters to rank candidates and also perhaps distribute points to different candidates.

As typical, I did not build forms for election setup, since it is so easy for the tech admin to use a SQL admin tool to set up the election. It's just the lowest priority for me but more important once I have moved on.