Extension:Page access restriction

This is a patch to enable page restriction under the MediaWiki software. Pages can be articles or categories. It adds a new |restrict| tab link allowing members of the group restrict to restrict pages. Users member of the group viewrestrict can read (and modify) the restricted pages. Other users cannot see, search, export, etc, the restricted pages. You can still |protect| them for editing.

A restricted page is distinguished by a red background tab, and you have a special page (Special:Restrictedpages) to list the restricted pages. All restriction/unrestriction actions are logged in the wiki log. It is also possible to restrict pages or namespaces by providing a regular expression array matching titles, and to restrict new pages by default. Optionally the user's pages can be restricted to their owner. Currently it is localized in English, German, Dutch, Swedish, Catalan, Finnish, Russian, Hebrew, Czech, Spanish and French.

This feature is mainly useful for intranet relying on MediaWiki as a non-encyclopedic content management system, like e-learning platforms or informational systems.

Written by Jej. More information at this site.

Get the patch
Download the patch, how to install, changelog, screenshots and comments here :
 * MediaWiki 1.5.x/1.6.xx
 * Note: This patch seems to be deprecated.


 * MediaWiki 1.4.x (deprecated)


 * MediaWiki 1.7.1 - You can find a (not very well tested) version for MW 1.7.1 here:
 * http://www.zedlitz.de/restriction-beta-0.8.mediawiki-1.7.1.patch
 * Note: This patch seems to be missing the SpecialRestrictedpages.php file. Otherwise it works fine for me --134.91.37.96 16:08, 22 November 2006 (UTC)


 * MediaWiki 1.10.x - I've updated the restriction-beta-0.8 patch to work (mostly) with MW 1.10.0 available here:
 * http://www.dolio.net/restriction-beta-0.8.mediawiki-1.10.0-v0.2.patch
 * http://www.dolio.net/restriction-beta-0.8.1.mediawiki-1.10.0-v0.2.patch (includes inverse regex function)
 * http://www.dolio.net/restriction-beta-0.8.2.mediawiki-1.10.0.patch (includes UserRead UserPageRestrict functions)
 * http://www.dolio.net/restriction-beta-0.8.3.mediawiki-1.10.0.patch (includes UserPagePrivate regex functions)
 * includes/SpecialImagelist.php is patched, but results in an empty table entry rather than no table row.
 * restricted images can still be included in non-restricted pages, and there's no way to restrict the file itself.


 * MediaWiki 1.11.1 - I've updated the patch from 1.10.x to work with 1.11.1:
 * http://www.trupoetry.com/patches/restriction-beta-0.8.mediawiki-1.11.1.patch


 * MediaWiki 1.12.0 - I've updated the patch from Marc(09/27/07)
 * http://home.zcu.cz/~honza801/restriction-beta-0.8.4.mediawiki-1.12.0.patch
 * Note: This patch seems to be missing the SpecialRestrictedpages.php file.


 * MediaWiki 1.13.2 - I've updated the patch from Marc(12/03/08)
 * http://ftp.disconnected-by-peer.at/pub/mediawiki-1.13.2-restrict-0.8.4.patch
 * this patch includes the SpecialRestrictedpages.php Page


 * MediaWiki 1.15.1 - I've updated my patch (06/02/10)
 * http://ftp.disconnected-by-peer.at/pub/mediawiki-1.15.1-restrict-0.8.4.patch


 * MediaWiki 1.16.0 - I've updated my patch --Geos one 14:17, 22 October 2010 (UTC)
 * http://ftp.disconnected-by-peer.at/pub/mediawiki-1.16.0-restrict-0.8.4-1.patch

Quick summary of what I did to get this running

 * Download the patch from the above site.
 * Add and customize this code to LocalSettings.php

Place the patch in the root folder of your mediawiki installation, in this example it's ./mediawiki-version. mv restriction-version.mediawiki-version.patch ./mediawiki-version cd ./mediawiki-version patch -p0 < restriction-version.mediawiki-version.patch
 * Apply the patch:

find. -name '*.rej'
 * Check for files that did not get patched properly:

cd ./mediawiki-version chown -R root:apache *
 * If necessary, reassign rights to the files that it patched:

chcon -R -t httpd_sys_content_t *
 * on SELinux you will also have to change the type of the patched files from tmp_t to http_sys_content_t


 * Add users to the restrict, viewrestric, and edituser groups:

By default nobody is able to restrict page. Go to the User rights management page (in special pages) and add users in group restrict (allow to view and restrict pages) or viewrestrict (allow only to view restricted pages). Another arbitrary groups authors in the example is granted edituser rights. Users with edituser rights can edit other users pages when $wgUserPageRestrict and $wgUserReadRestrict are true, but do not gain restrict nor viewrestrict rights. In the example authors could very well be changed to edituser to match the other new groups but authors is used to demonstrate the difference between a user group and a user right.

If $wgUserPageRestrict is true, user pages are restricted to their respective owner, as well as members of the viewrestrict group. If $wgUserReadRestrict is also true then users are allowed to read but not edit other users pages and sub pages, unless they are members of a group with edituser rights. Users discussion pages will also become editable if $wgUserReadRestrict is true.

Don't write sensitive information in page titles, they could be retrieved in some cases. This is beta and GPL, test and feedback welcome !

How to help

 * You can test, report bugs, and try to find security holes (related to this restrict feature).
 * You can propose ideas, improvements, etc.
 * There is work to do to translate the messages in different languages. The texts to translate are :

Have a look in the language file : /languages/MessagesXx.php where Xx is the country/language code. Becareful, the charset is UTF-8. Please work on the last Mediawiki stable version.

Currently available :
 * English
 * French
 * German (thanks to Dr. Walter H. Schreiber)
 * Dutch (thanks to Peter De Baets)
 * Swedish (thanks to Samuel Lampa).
 * Catalan (thanks to Pau Cabot)
 * Finnish (thanks to Tuomas Helin)
 * Russian (thanks to T O X I N)
 * Hebrew (thanks to Yuval Hager)
 * Polish (thanks to Janusz 'Ency' Dorozynski)
 * Czech (thanks to Michal Ciza)
 * Spanish (thanks to Victor Fariña from Queres tecnologias)

You can send your contribs to restrict-mediawiki /at/ conseil-recherche-innovation.net. Please subscribe to the mailing list so I can contact users and contributors easily (restrict-mediawiki-list-subscribe /at/ conseil-recherche-innovation.net).

Inverse Restriction
New Feature for restrict version beta-0.8.1

Replace the isRegexRestricted function in includes/Title.php (version 1.7.1) with the following:

You can then get inverse restriction by using this format in LocalSettings.php: Which makes any pages starting with "Public" non-restricted and all others restricted.

I have included this patch into my restriction patch against MediaWiki 1.7.1: http://www.zedlitz.de/restriction-beta-0.8.1.mediawiki-1.7.1.patch

Readable Restricted Users Pages
New Feature for restrict version beta-0.8.2

A new option $wgUserReadRestrict = false; and user right edituser have been added by making a few additional changes to includes/Title.php. When $wgUserPageRestrict is true users can only view their own user pages, but not their own sub pages. When $wgUserReadRestrict is also true users are allowed to read but not edit other users pages and sub pages, but other users talk or discussion pages can be edited by others. Users can be granted edituser permissions which will allow users without 'restrict nor viewrestrict rights to edit other users pages and sub pages. If $wgUserPageRestrict is true and $wgUserReadRestrict is false users with edituser rights can neither read nor edit other users pages nor talk page so this right has no effect in this case.


 * See Talk:Page_access_restriction_with_MediaWiki for early development of what would become this feature in beta-0.8.2.


 * Notice: When $wgUserPageRestrict is true users are not allowed to edit their own user sub pages, eg: User:Me/Sub. Enabling $wgUserReadRestrict "fixed" this behavior, but the core bug remains and should be addressed in the future.
 * Notice: The code which allows users with viewrestrict or edituser rights to view and edit other users sub pages when $wgUserReadRestrict is true uses an odd method to determine if an article is a users sub pages. Using (substr_count($this->getText, $wgUser->getName) could allow injection of a username into page titles.  Not sure if this is a security risk or just an odd quark, but this method of matching should be addressed along with the $wgUserPageRestrict sub page issue. --D0li0 00:10, 23 May 2007 (UTC)

Readable and Private Users Pages
New Feature for restrict version beta-0.8.3

A new option $wgUserPagePrivate = array("^Secure", "^Private"); has been added by making a few additional changes to includes/Title.php. When $wgUserReadRestrict is true and $wgUserPagePrivate is defined users can view other users pages except for those which match any of the regular expressions defined in the array. In this case any users subpage with Secure or Private in it's title will only be readable by the owner of that page. --D0li0 06:28, 11 July 2007 (UTC)
 * Notice: The article is not readable by those with restrict, viewrestrict, editusers, nor sysop rights.
 * Notice: The edit and summary of such pages are still visible in the recent changes
 * Notice: Users with export rights can export such articles. Appears to be fixed, thought not due to caching perhaps?
 * Notice: Portions of such pages may be returned as search results. Appears to be fixed, thought not due to caching perhaps?

Todo

 * Texts translation.
 * Images are partialy protected (HTTP access still possible).
 * Being able to define other groups than sysop, bureaucrat : ex. group A of students, group B...
 * Version that works fine with Mediawiki-1.7.XX