Extension:WhiteList

Overview
In some corporate environemnts which use wikis for their documentation, it is sometimes necessary to restrict access to information. There are several ways to do so. One such technique is using Extension:Blacklist to blacklist certain pages. However, in cases where some users need to be explicitly restricted to only a few specific pages, the blacklist approach becomes cumbersome. Instead, a whitelist can be used to define these restrictions.

As is evident in User Rights Extensions overview, the WhiteList extension is probably one of the more flexible pure extensions. That is, there is no need to modify any of the main MediaWiki code.

Description
This extension adds two new groups and two new user rights: a set for the managers and a set for the restricted users. A manager has the permissions to view a new Special Page to oversee all restricted users' pages. A manager can define specific pages to be visible to a restricted user. These permissions can be Any user belonging to the Manager group or who has the Manager rights will have all of these capabilities. A sample screenshot of these capabilities along with a more detailed description is below.
 * set to either view or edit that page
 * set to autoexpire or never expire
 * removed altogether

Once a user is defined as a restricted user, the only pages they will be allowed to see are the default whitelist pages (i.e. Special:Preferences, User:Username, etc) and all whitelisted pages explicitly defined for them by a manager. All restricted users will have a new Personal Tab called My Pages which will list only the pages they have access to. When viewing this page, the restricted users have the ability to request additional page access (which basically sends an email to their manager which formally states the request).

Usage
The main page of the extension is divided into two sections. The top portion entitled Current information for Some User details all of the currently whitelisted wiki pages for the selected restricted user. The bottom portion entitled Add new pages to Some User's whitelist is for defining new whitelist pages for the currently selected restricted user.

Current Whitelist Pages
This table contains 6 columns. Each row corresponds to one whitelisted page for the currently selected restricted user. The title of this page is in the Wiki Page column. A manager can verify that this page really should be whitelisted by clicking on the title which takes then to that page. The other columns to the right are detailed below:
 * Access Type - lists what kind of access was given to the resitricted user for this page. There are only two options: edit and view.
 * Expires On - lists when the restricted user's whitelist access for this page will automatically expire. This could be a date, either in the future, which means that the restricted user still has the ability to access that page, or it could be a date in the past, which means that the restricted user's whitelist access to this page has expired. A blank entry means that there is no expiration date for access of this page.
 * Last Modified By - lists the name of the manager who last modified the permissions this restricted user's access to this page.
 * Last Modified On - lists the date on which the manager who last modified the permissions this restricted user's access to this page did so.

The manager interacts with this restricted user's current permissions by selecting one or more pages in the Modify column by clicking on the checkboxes. In case the manager wants to interact with all listed pages at once, they can click on the All or None links in the column heading which checks or clears all checkboxes, respectively. The action to perform on the pages checked in the Modify column are detailed below the table. A manager can select only one of the following actions: Once the pages and the action are defined, the manager needs to click on the Process button.
 * Change Expiry Date - set the Expires On date for all selected pages to the date defined in the New Date field to the left. For manager's convenience, clicking on New Date brings up a JavaScript calendar. Remember, the New Date can be left blank to indicate that page access will never expire.
 * Set to Edit - set the Access Type permissions for all selected pages to Edit.
 * Set to View - set the Access Type permissions for all selected pages to View (read only).
 * Remove - removes all selected pages from the restricted user's whitelist

New Whitelist Pages
This table contains a textbox which can be used to add new wiki pages to the restricted user's whitelist access. The entries are all treated as wiki titles (both articles and categories, both existent and nonexistent) and are parsed as one title per line. Currently, pages need to be explicitly whitelisted. However, work is in progress to define whitelisted pages via wild cards (i.e. all pages in Category:Something).

Once all new pages are defined, the manager needs to define what kind of access to give to the restricted user for all of these pages. The manager can define: Once the pages and the action are defined, the manager needs to click on the Process button.
 * Expiry Date - defines when the restricted user's access to all of the newly defined pages will expire. Remember, the manager can enter the date either with the JavaScript calendar by clicking on the Expiry Date link, or they can leave it blank to make the access never expire.
 * Set to View or Set to Edit - defines whether the access type for all newly defined pages should be View or Edit.

Viewing WhiteListed pages for Users
As it was pointed out earlier, restricted users can find out which pages they are restricted to by clicking on their My Pages personal URL (typically in the upper right hand corner of every page). Clicking on this link actually takes them to Special:WhiteList page. This page is effectively blocked for every non-restricted users because for them it does not make sense to see page restrictions since they are not restricted. However, non-restricted users may have a need to sometimes see which pages restricted users are allowed to see. To do so, non-restricted users can go do Special:WhiteList/userid where userid is the user ID of a restricted user. Note: this functionality is different than the one allotted for managers via Special:WhiteListEdit; managers can add/remove/change permissions for a restricted user's whitelist, whereas non-restricted users who are not managers can only view restricted user's whitelist.

Install Prerequisite Extension
Follow the installation instructions for Extension:Usage Statistics. Note: since this extension is only needed for one function, you don't actually have to install the gnuplot extension if you don't want to, however doing so will impair the functionality of the Usage Statistics extension.

Install the actual extension
Download the extension code (all files) from SVN and place it in the extensions/WhiteList/ directory.

Create the MySQL table
Make sure to use the appropriate $wgPrefix. In this example, we used wiki_ as the $wgPrefix.

Setup the system messages
Go to your Special:Allmessages page and set an appropriate message for
 * badaccess-group1
 * badaccess-group2
 * badaccess-groups

Enable the extension
Add the following text to your LocalSettings.php NOTE: you may also want to add other pages that should be globally whitelisted to all restricted users in the $wgWhitelistOverride['always']['read'] or $wgWhitelistOverride['always']['edit'] arrays.

Configure Users
Before the extension can be used, a sysop has to add the desired users to the manager group. Note, by default, a sysop will not have the necessary permissions to see the manager's Special:WhiteListEdit page. So, it might be a good idea to add the sysops to the manager group also.

Next, assign whomever you want to restrict to the restricted group. Now, any user with the editwhitelist userright (i.e. managers) can modify the restricted users' whitelist.

Security Issues
This is an attempt to document how the Whitelist extension copes with various security concerns described at Security issues with authorization extensions. Note that, while this system is in production use, the extension authors make no warranty that the following information is complete or accurate (although we believe it to be so). If you find any security issues with this extension that are not described here, please let us know on the talk page.

There is a greater change of security issues in the read protection system, due to MediaWiki's architecture. So, denying read access should be seen as a "nothing to see here, move along," sort of thing rather than a absolute guarantee of secrecy.

To Do
This extension is still actively being worked on, so there may be a number of improvements yet to come. The short list of improvements includes:
 * Highlight the expiry dates that have expired in red
 * add wild card whitelist access (to be added in v0.8)