Modifying Oddmuse
Oddmuse is a wiki script written in perl. It is based on the Usemod wiki script, but can produce valid xhtml. Oddmuse does not need a database, page data is stored in text files.
To get a wiki running on a Web server that runs Apache (1.2 upwards) and that can run perl cgi scripts, you just need to
- specify the path to the data folder
- set the configuration variables to reflect how you want the wiki to work
- upload the script to the cgi-bin of your Web server
- create the data folder and set permissions appropriately (755 for the script and 777 for the data folder).
There are specific instructions for Windows XP, Mac OS X and a Gnu/Linux system. There is also some information on the configuration settings.
Oddmuse offers some ‘advanced’ facilities including,
- File upload, you create a page to hold the file, and then edit that page. In the editor box, the phrase ‘replace this text with a file’ appears. Follow that link and browse for your file and click the upload button. The page now contains only a link to the file. Any text has been overwritten by the file link
- Rollback, if the wiki is set so that anyone can edit the pages, then if the user sets a user name, then that user can roll back a page to a previous version – that results in later versions being lost
- Allow any visitor to edit
- Allow only some people to upload files and ‘roll back’ pages to earlier states
- Forget about users once the browser has been closed – the wiki will be used on shared computers during an event
Rollback
Unfortunately, any visitor who sets a ‘username’ by typing their username into the box on the editing page can then rollback the history of pages. The implicated code is on line 1917 in the subDoHistory function.my $rollback = UserCanEdit($id, 0) &&
(GetParam('username', '') or UserIsEditor());The logic is as follows: Rollback if users can edit AND (user has set a user name OR user is the editor)
I changed the logic to
my $rollback = UserCanEdit($id, 0) && UserIsAdmin();or, in English, Rollback if users can edit AND user is an admin. That will stop users accidentally rolling back a full page to the first edit. Those with the admin password can roll pages back in the case of a complete foo-bar due to layout codes or the ‘she who saves last wins’ issue.
Cookie expiry
Oddmuse sets a cookie, and the default script has a cookie expiry set to 2 years after last use. If someone typed the admin password on a Web browser in a drop-in IT room, that machine would have all rights until the cookies were next deleted. The code is on line 2205 in the subCookie function…sub Cookie {
my ($changed, $visible, %params) = CookieData();
# params are URL encoded
if ($changed) {
my $cookie = join(UrlEncode($FS), %params);
# no CTL in field values
my $result = $q->cookie(-name=>$CookieName,
-value=>$cookie,
-expires=>'+2y');
$Message .= $q->p(T('Cookie: ') . $CookieName . ', '
. join(', ', map {$_ . '=' . $params{$_}}
keys(%params))) if $visible;
return $result;
}
return '';
}I changed line 2205 to read
-expires=>'';
i.e. I set no expiry so the cookie will expire after the current session, when the user quits the browser. Some Web pages about cookies suggest setting a cookie expiry in the past. In that case, MS Internet Explorer expires the cookie as soon as the cookie is created. I must admit that behavior does strike me as more logical than the Netscape response of expiring the cookie after the browser closes.
Oddmuse is written in a well structured way and I was able to work out which functions contained the code I needed to change. I could also be confident that changing the subDoHistory function would not change (say) the alignment of lists, or the handling of images. I was able to customise this lightweight server application for my needs in about an hour.