Hack30.Collaborate Safely with a Secured Wiki

Hack 30. Collaborate Safely with a Secured Wiki

Get out of the business of coding, supporting, debugging, and maintaining project collaboration sites by using a tool that allows users to create their own sites.

If you're a busy webmaster trying to perform systems work, the last thing you need is yet another user coming to you with a request to build and host another web site or to install yet another content management solution. Instead, promote a Wiki solution that can be up and running in seconds, ready for the user to create and edit content with no further help needed from you.

Wikis evolved around the idea that content can be editable by anyone who happens upon the site and sees a mistake or has something to add. Webmasters and system administrators alike were wary of this concept, which sounded like an idea just waiting to be completely abused by spammers, digivandals, and the like. If you last looked at Wiki solutions when the buzzword was fresh off the front page of Slashdot and wrote them off as unmanageable or as security issues waiting to happen (like I did), I urge you to have another look.

MediaWiki is the powerhouse Wiki application that runs the http://wikipedia.com web site. Since Wikipedia runs the most visible Wiki site in the world and prides itself on being a resource for the people by the people, what better endorsement do you need for a Wiki application?

Wikis need not be unsecured free-for-alls. Nowadays, you can configure MediaWiki to authenticate to your internal LDAP server, completely disallow anonymous edits, and greatly restrict the damage that can be done to your Wiki site. In addition, MediaWiki makes it very easy both to track changes to the pages of their sites, and to revert to older copies of the pages.

So why use a Wiki if you're just going to lock it down? Wikis make wonderful content management solutions, for one fundamental reason: they make absolutely no assumptions about the purpose of your site. Many of the LAMP-based, open source content management solutions are built around the concept of a news distribution site firstextensions to do everything else, from blogging to forums and weather to file repositories, are added later, often by members of the respective user communities. If you're not planning to run a news site, you wind up having to find some hack to make your content management site act the way you want. If you use extensions to make your site work, you can't just upgrade right away and assume everything will still function correctly.

I've used dozens of open source content management solutions and, depending on your needs, you'll probably find many of them to be adequate. But if you support users in academia, R&D, or internal departments, each project group may have different needs. A simple framework that puts the power to structure and format the content in the hands of the content creators and users is a powerful tool, and the ability to restrict access and edits in a number of ways will give both you and your users peace of mind. If they want a "wide open" site, and you allow for that, that's no problem. But if you have other security requirements, chances are that with MediaWiki you can implement them easily.

MediaWiki allows you to authenticate to a backend LDAP server or database connection, and there are patches available to rely on other authentication methods available in your environment. In addition, you can opt to restrict access such that only registered and logged-in users can edit pages, create a more open site where anyone can edit pages, or disable registration altogether to create a site for internal staff documentation.

4.3.1. Installing MediaWiki

Another nice benefit of MediaWiki is that it's a breeze to install. It does require PHP, and its creators strongly suggest using MySQL as the backend database. Depending on the features you want to use (for example, image thumbnailing or LDAP authentication), you may need PHP to be compiled against specific libraries, but the requirements to run a simple site are pretty slim.

If you're hosting your own site (i.e., you have root privileges), installation takes, quite literally, seconds. All you do is untar the distribution into the document root of your web server, and go to the site! MediaWiki knows if it's your first visit, and prompts you to perform an installation. Once you supply the MySQL administrator password, MediaWiki will create a new user, a new database, and all the necessary tables, which is 90% of the installation process.

If you're running MediaWiki on a hosted remote server, however, you're not likely to have a root password or an administrative password for MySQL. In this case, you'll want to create the MediaWiki database first, and then point the installation at this database to create its tables. Unfortunately, I can't tell you how to do this, as every hosting service will provide different tools to assist you.

Once the installation has been performed successfully, you'll be presented with a link to visit your new site.

4.3.2. Configuring MediaWiki

Installing it was easy, but how do you lock this thing down? There's about a metric ton of documentation available on how to do this, but I'll summarize some of the features that are of primary importance to administrators.

First and foremost is site access. Many sites haven't deployed Wikis because they're under the illusion that they can't be secured. Not so!

With Version 1.4 of MediaWiki, it's possible to use the configuration file and/or a few SQL statements to change the functions available to different types of users. Version 1.5, on the other hand, has quite a robust collection of potential roles that users can play, implemented via user groups. We'll work with Version 1.5 here, because it'll likely be in its final form by the time this goes to press.

I'm working with 1.5rc4, which can be managed largely in a browser. There are separate pages for adding, deleting, and blocking users. There is also a page for changing the groups to which users belong, which will affect the rights they have when they visit your site. In addition, there are plug-ins available to help you correlate users with all the known IP addresses used by them and perform other functions not available in the main distribution.

However, there isn't yet an interface for changing the rights for a group, or adding/deleting groups. For those tasks, you'll need to have shell access to the web server, or you'll need to create a local copy of the LocalSettings.php file, edit it, and copy it back into place to make the changes take effect. The file is simple to edit, and the documentation for making the changes is more than adequate, but I'll go over examples of one or two quick changes you might want to make.

If you just want to change the group a user is associated with, you can log in as an administrative user and go to the Special Pages link. At the bottom of the screen you'll see Restricted special pages that are listed only when the admin is logged in. This section contains the link to the user rights management page, which is currently just an interface to change the group memberships of specific users.

If you want to create a group, you'll need to edit LocalSettings.php and set up the rights available to the group. To see how the default groups are set up, check the documentation or open up the includes/DefaultSettings.php file in your install directory. Here are the lines you would add to LocalSettings.php to add a group called newgroup with permission to read and edit but not to delete:

 $wgGroupPermissions['newgroup']['edit'] = true; $wgGroupPermissions['newgroup']['read'] = true; $wgGroupPermissions['newgroup']['delete']= false; 

As you can see, there's no explicit "create group" function. Assigning rights to a nonexistent group, as I've done here, will cause the group to be created, and it will be listed as an available group the next time you go to the user rights page.

Keep in mind that there are global settings as well, for the all group (represented in the configuration as *). Here are a few default settings for that group from the DefaultSettings.php file:

 $wgGroupPermissions['*' ]['createaccount'] = true; $wgGroupPermissions['*' ]['read'] = true; $wgGroupPermissions['*' ]['edit'] = true; 

If you want to override these settings, just place similar lines in the LocalSettings.php file, setting the appropriate permissions to true or false as desired. The LocalSettings.php file overrides any corresponding settings that may be found in the DefaultSettings.php file.

This model gives you the flexibility to, for example, disable anonymous users from creating accounts at all or allow them only to read, and to require users to log in to edit anything. There are also additional rights you can give users to make them quasi-administrators, allowing them to create accounts for other users, delete files, and roll back bad edits.

4.3.3. Getting Started: Data Structure

Once user access is out of the way, probably the most important decisions you'll make in running your Wiki have to do with how the content on your site will be structured and how your content best maps to the organizational elements available to you in MediaWiki. There are many useful tools you can use, and all of them are fairly genericagain making no assumptions about the purpose of the site.

There are many ways to use the various organizational elements. If you have just one project group, they can have their own Wiki devoted to their project. However, you could potentially have several projects share a single Wiki by providing separate namespaces on the site. A namespace is the highest-level data element provided in MediaWiki. Within the namespaces are categories, that the project maintainers themselves can use to break up their sites into various pieces that make sense for their needs.

Lest you think the pages of the site need to be completely static documents, have a look at the Templates feature of MediaWiki, which allows you to embed documents within various pages. This gives you the flexibility to, for example, make your main page nothing but a collection of various other documents placed into the main page. Maintainers of the various templated pages can then update their own content, and changes will be reflected on the main page without affecting templates created by other users.