Extension:Page access restriction

MediaWiki extensions manual - list

Page access restriction Release status: unknown
Implementation	User rights
Description	Adds a restrict tab to the page bar so that authorized users can decide who may view that page.
Author(s)	Jej (Jejctalk)
License	No license specified
Download	see below
Check usage (experimental)

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.17.0 - Here is a version which should work on Mediawiki 1.17.0 I have not thoroughly tested this, so please use at your own risk (Uploaded 29 June 2011)

mediawiki-1.17.0-restrict-0.8.4-2.patch

• MediaWiki 1.18.1 - Based on Tavis King's 1.17.0 patch; works for me but use it at your own risk (and tell me if something goes wrong)

http://mikedld.com/f/mediawiki/mediawiki-1.18.1-restrict-0.8.5.patch

I took the liberty of incrementing version to 0.8.5. I've also

• refactored the code so checks for global properties are more or less centralized
• patched search classes so that user is not able to find restricted pages, but I did that blindly for all DB plugins except MySQL
• added default settings from #Quick summary of what I did to get this running section to DefaultSettings.php, so you only need to override necessary options in your LocalSettings.php
• fixed encoding issues with some translations, everything seems to be in valid UTF-8 now
• added localized aliases for the RestrictedPages special page, moved it to 'maintainance' group and made visible to users with 'viewrestrict' rights only
• resurrected $wgHideRestrictLog (was not working)
• and sorry, but I removed almost all the comments, hopefully someone else might want to correct this

--Mike.dld 16:24, 4 February 2012 (UTC)

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

/**
* If true, a new menu action allows to restrict pages access to 'restrict' group users.
* If false, all previously restricted pages are accessible again.
*/
$wgEnableRestrict = true;
 
/**
* If true, new pages are restricted by default for 'restrict' group users.
*/
$wgRestrictNewPages = false;
 
/**
* If true restrict user pages to their owner (as well as viewrestrict/restrict members)
*/
$wgUserPageRestrict = false;
 
/**
* when wgUserPageRestrict and this option are true, allows user pages to be read but not edited by others?
* added to restrict version beta-0.8.2
*/
$wgUserReadRestrict = false;
 
/**
* Regular expression array to restrict matching pages
* eg. $wgRegexRestrict = array("^Secure:", "^Secret ");
*     restrict all pages where title is like 'Secure:...' or 'Secret ...'
* with restrict version beta-0.8.1 you can also use Inverse regex matching
* eg. $wgRegexRestrict = array("!!Public.*", ".*");
*     any pages starting with "Public" is un-restricted and all others are restricted.
*/
$wgRegexRestrict = array();
 
/**
* If true do not add recent changes entry for restricted pages
*/
$wgNoRecentChangesRestrict = true;
 
/**
* If true hide log entries related to restriction, except for 'restrict' or 'viewrestrict' users (Special:Log page)
*/
$wgHideRestrictLog = true;
 
/**
* MediaWiki permissions setup
*/
$wgGroupPermissions['restrict']['restrict'] = true;
$wgGroupPermissions['restrict']['viewrestrict'] = true;
$wgGroupPermissions['viewrestrict']['viewrestrict'] = true;
// with restrict version beta-0.8.2 when $wgUserPageRestrict and $wgUserReadRestrict is true
// 'authors' group members get 'edituser' rights and can edit other users pages and sub pages.
$wgGroupPermissions['authors']['edituser'] = true;

• Apply the patch:

I recommend creating a copy of your mediawiki root folder to a temporary location such as /tmp/mediawiki-patch/

cp mediawiki /tmp/mediawiki-patch/mediawiki-1.17.0

Put the patch in the same location as the root of your mediawiki installation.
Rename your mediawiki root folder to mediawiki-version, for example; if you are running 1.17.0, name your mediawiki root folder mediawiki-1.17.0
ls -l /tmp/mediawiki-patch should give you the following files:

mediawiki-1.17.0
mediawiki-1.17.0-restrict-0.8.4-2.patch

Now type in the below to apply the patch

cd /tmp/mediawiki-patch
patch -p0 < mediawiki-1.17.0-restrict-0.8.4-2.patch > patch.log

patch.log will show you any errors that may have been generated.

• Check for files that did not get patched properly:

find . -name '*.rej'

• If necessary, reassign rights to the files that it patched:

cd ./mediawiki-version
chown -R root:apache *

• on SELinux you will also have to change the type of the patched files from tmp_t to http_sys_content_t

chcon -R -t httpd_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 :

'restrict' => 'Restrict',
'restrictthispage' => 'Restrict this page',
'unrestrict'    => 'Unrestrict',
'unrestrictthispage' => 'Unrestrict this page',
'restricttitle' => 'Restricted page',
'restricttext'  => 'This page is restricted. To view it you have to be member of the \'restrict\' group or \'viewrestrict\' group.',
'restrictedpages' => 'Restricted pages',
'restrictlogpage' => 'Restriction_log',
'restrictlogtext' => 'Below is a list of page restrictions. See [[{{ns:4}}:Restricted page]] for more information.',
'restrictedarticle' => 'restricted [[$1]]',
'unrestrictedarticle' => 'unrestricted [[$1]]',
'restrictsub' => '(Restrict \'[[$1]]\')',
'confirmrestrict' => 'Confirm the restriction',
'confirmrestricttext' => 'Do you really want to restrict this page?',
'restrictcomment' => 'Reason for restricting',
'unrestrictsub' => '(Unrestrict \'[[$1]]\')',
'confirmunrestricttext' => 'Do you really want to unrestrict this page?',
'confirmunrestrict' => 'Confirm unrestriction',
'unrestrictcomment' => 'Reason for unrestricting',
'restrictreason' => '(give a reason)',
'tooltip-restrict' => 'Restrict this page',
'notallowedtomoverestrictedpagetext' => 'To move this page, you have to be member of the \'restrict\' group.',
'restrictedpagespagetext' => 'This page lists all restricted pages in the wiki. ',
'regexrestrictedpagespagetext' => 'All page titles matching this/these regular expression(s) are also restricted : ',

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:

        function isRegexRestricted() {
                global $wgEnableRestrict, $wgRegexRestrict;
 
                if ( $wgEnableRestrict == true ) {
                        foreach ( $wgRegexRestrict as $k=>$v ) {
                        // Reverse restriction START
                        // If an entry starts with "!!" and the remaining string matches the namespace,
                        // the page is NOT restricted 
                                if (substr($v, 0, 2) == "!!") {
                                        if (ereg (substr($v, 2), $this->makeName( $this->mNamespace, $this->mTextform) ) ) return false;
                                } else  
                        // Reverse restriction END
                                if ( ereg ( $v, $this->makeName( $this->mNamespace, $this->mTextform) ) ) return true;
                        }
                }
                return false;
        }

You can then get inverse restriction by using this format in LocalSettings.php:

$wgRegexRestrict = array("!!Public.*", ".*");

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#UserPageRestrict.3Dtrue_.28read.2C.21edit.29 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

See also

• Manual:Preventing access, native MediaWiki features.
• Extension:Hidden pages, solution based on namespaces.
  • The hiddenwiki patch is a namespace based restriction patch which uses groups to restrict whole namespaces. It appears to be a fairly solid and well written patch, more so than this Restrict patch which could perhaps be merged into hiddenwiki? There are a few conflicts with this Restrict patch, depending on the order applied, which must be resolved by hand in ./includes/QueryPage.php.rej ./includes/SpecialMostlinked.php.rej and ./includes/Title.php.rej.
• Extension:PageProtection extension, mark articles's areas and sections as protected from reading with a <protect>...</protect> tag
• PageSecurity extension.
• Extension:Lockdown