Laboratoire pédagogique du Greta du Velay

Laboratoire pédagogique du Greta du Velay

Restrict pages under MediaWiki

Temps de lecture estimé à 5 min. 30 sec.
(Voir le billet en français)

This patch is deprecated.

Here is a patch to enable article restriction under MediaWiki. 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. Others 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 loggued 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. Optionaly the user's pages can be restricted to their owner. Currently it is localized in English, German, Dutch, Swedish, Catalan, Finnish, Russian, Hebrew, Polish, Czech, Spanish and French. This feature is mainly useful for intranet relying on WikiMedia as a non-encyclopedic content management system, like e-learning platforms or informational systems. To respect the wiki philosophy, it is not appropriate to use it to restrict public access! To install restriction-patch, download MediaWiki (do a security backup if you patch your own installation), or see below to dowload a pre-patched archive.

Apply patch

mv restriction-version.mediawiki-version.patch ./mediawiki-version cd ./mediawiki-version patch -p0 < restriction-version.mediawiki-version.patch

Configure

First, install MediaWiki as usual (to create the database and the LocalSettings.php file). Once your wiki works fine you have to enable restriction. It is disabled by default. So add in your ./LocalSettings.php file (at the bottom of the file) :
/**
  * 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;
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). Here is a FAQ on metawiki. If $wgUserPageRestrict is true, user pages are restricted to their respective owner, as well as members of the viewrestrict group. Don't write sensible information in page titles, they could be retrieved in some cases. This is beta and GPL, test and feedback welcome !

Get the patch

Mailing list and contact

You can subscribe to the mailing list to discuss about this patch, receive news, etc. Send an empty mail to restrict-mediawiki-list-subscribe@... and reply to the confirmation mail. To contact me (no personal support, use this blog) : restrict-mediawiki/at/conseil-recherche-innovation.net (Jérôme Combaz)

Changelog

Version beta-0.72 for MW 1.6.6/1.6.7/1.6.8 (09-01-2006)
  • Spanish translation (thanks to Victor Fariña from Queres tecnologias)
  • Czech translation (thanks to Michal Ciza)
Version beta-0.71 for MW 1.6.6/1.6.7 (07-13-2006)
  • Two bugs in Articles.php and Skin.php (thanks to Owen, see here)
Version beta-0.70 for MW 1.6.6/1.6.7 (06-06-2006)
  • SQL requests are not modified anymore to check the restriction (better sustenability of the patch)
  • Now restricted pages and *regex* restricted pages are treated in the same way. So none of pages title should be listed whatever the protection mechanism choosed, nor during a search request
  • Regex restriction include the namespace, so it is now possible to restrict whole namespaces (eg. "^Talk:" restrict all talk pages)
  • Image partialy restricted (not listed but file accessible via HTTP)
  • The SpecialVersion page informs that MW is patched
  • Correction of text error on the unrestrict page (thanks to Mathaba)
  • Polish translation (thanks to Janusz 'Ency' Dorozynski)
Version beta-0.64 for MW 1.6.3 (05-01-2006)
  • Bug in SpecialCategories page (thanks to T O X I N)
  • Hebrew translation (thanks to Yuval Hager)
  • Bug in OutputPage.php (thanks again to Yuval Hager)
Version beta-0.63 for MW 1.6.3 (04-20-2006)
  • Upgrade for 1.6.3 (thanks to Anthony for his help)
  • Russian translation (thanks to T O X I N)
  • Finnish translation (thanks to Tuomas Helin)
Version beta-0.62 for MW 1.5.5/1.5.6 (02-13-2005)
  • Catalan translation (thanks to Pau Cabot)
  • Small mistake (comma) in swedish translation
Version beta-0.61 for MW 1.5.5/1.5.6 (01-18-2006)
  • Swedish translation (thanks to Samuel Lampa)
  • Dutch translation (thanks to Peter De Baets)
Version beta-0.6 for MW 1.5.3 (12-15-2005)
  • $wgHideRestrictLog option is back
Version beta-0.59 for MW 1.5.1/1.5.2 (10-31-2005)
  • Allow to restrict new pages by default ($wgRestrictNewPages option)
  • Bug : 'ArticleProtectComplete' hook function remplaced by 'ArticleRestrictComplete' (stupid mistake !)
Version beta-0.58 (10-07-2005)
  • Restriction by regular expression test on title.
  • Bug which avoided to view restricted pages in special pages (only 'restrict' group can see it, not possible to add 'viewrestrict' group) (thanks to Karen O'Flaherty)
  • German translation updated (thanks to Hugo Wirz)
  • French and english translations updated.
  • Bug in Broken Redirects special page SQL request
  • Categories special page hide restricted categories for non allowed users
  • No more modifications in monobook stylesheet than one style added (see bottom of /skins/monobook/main.css file).
Version beta-0.57 (09-18-2005)
  • Stupid cosmetic bug which avoid patch working if user page restriction enabled (thanks to Christophe Berger)
Version beta-0.56 (09-11-2005)
  • Bug "variables can be passed by reference in mediawiki\includes\Article.php on line 1703" with some PHP configurations (thanks to Chunho Lee)
Version beta-0.55 (09-07-2005)
  • First public release for MediaWiki 1.5

Commentaires

Please, add your comments below, or subscribe to the mailing list (see above)

Jerome

Hello,

I tried your patch for page access restriction. But when I pressed the "confirm" button on the "restrict" tab, it caused an error with the following message:

Fatal error: Only variables can be passed by reference in [mediawiki]\includes\Article.php on line 1703

I have mediawiki 1.5rc4, mysql 4.1, apache2 2.0.54 and php 5.0.5 running on a Windows XP SP2 system.

What could be the source of the problem? PHP?

Thanks.

Chunho

DEPRECATED, thanks for your help. Hello Chunho Lee,

The source of the problem is probably a too permissive configuration of my PHP installation :)

Please could you try this new patch on a fresh install ? conseil-recherche-innovat... (for a full patched archive : conseil-recherche-innovat... )

or just change in Article.php near 1703 :

$getredit = $this->mTitle->getRestrictions('edit');
$edit = "edit=".current($getredit);
$getrmove = $this->mTitle->getRestrictions('move');
$move = "move=".current($getrmove);

Thanks,
jej

Hello Jerome,

Thank you so much for your prompt response. I tried your suggestion (by directly editing the Article.php) and it worked without any further problem. But now the color scheme of the "unrestrict" tab link does not look correct. The text color is white and when viewed against almost gray background, it is not legible. Do you have a solution to that problem?

Thanks again.

Chunho

arwfff... probably a non-compliant browser ? Did you try to browse with firefox, and what is the visual result ?

jej

I've gotten this installed and (seemingly) configured correctly, but there's one problem: anonymous users can still view restricted pages. All other restriction properties work fine; nobody can edit a restricted page (or delete one), it's just that anybody can view them whether in the "viewrestricted" group or not. I don't know how to manipulate group permissions for "anonymous," but the Special:Permissions extension shows the anonymous user is not in the "restrict" or "viewrestrict" groups.

Any ideas?

Using Mediawiki 1.5rc4.

Thanks!

Strange... It works perfectly for me for anonymous users. Did you set $wgEnableRestrict = true in LocalSettings.php ?

jej

Yes. In case it matters, I have made some minor changes to the default permissions. Here's the entire relevant section:

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

$wgGroupPermissions['user' ]['move'] = false;
$wgGroupPermissions['user' ]['edit'] = false;

$wgGroupPermissions['sysop' ]['move'] = true;
$wgGroupPermissions['sysop' ]['edit'] = true;

$wgEnableRestrict = true;

The patch applied cleanly, by the way, against the 1.5rc4 installation I'm running.

Actually, some additional notes.

A page I marked as restricted does NOT appear in search results or special pages ("dead end pages," etc.). However, typing the page's title directly *does* produce the page's content as normal for anonymous users even when it's restricted.

Hi Will,

Well, it's difficult to answer you, as it works as expected on my installation.

- Did you patch an already existing installation ?
- Could you please test a fresh install from the full archive provided above ?
- Could you send me your LocalSettings.php to the contact email ? (remove database passwd if needed)

It's normal that restricted pages are not shown to non allowed users in special pages. Allowed users should see it. But access should be forbidden for non 'restrict' or 'viewrestrict' users in every cases...

jej

Do you have a specific changelog between patch 0.56 and 0.57...I don't want to have to remake the site if I don't have to...

thanks

This extension is fantastic! However, I am now having a problem getting an rss feed for several pages. Any ideas??

Sure, I'll give it a stab in the next couple of days just to make sure it's not something funky on this end. I'll also dig through the code some more to try to get my mind wrapped around how MediaWiki decides whether to show a page or not (I need to understand that process anyway) and see if I can't track this one down myself.

Thanks for the suggestions :)

Hello Jerome

Thanks for that great script! Any hint: in monobook/main.css the li#ca-unrestrict a { color: white; } should be a different color to see the text on tab (see message 4 from Chunho Lee). In german language file the 'umlaute' are displayed as &auml; &uuml; etc., I replaced them by ä, ü etc., then it works correct in german version...;-)

Hola,

Thanks everybody for your comments. I am away for some days, so I will look closely next week. To be quick :

- kyle : you don't have to re-install if $wgUserPageRestrict = true. Anyway see the changelog above :) For the rss, not sure the patch is involved... I will have a look.
- huwi : it's ok under mozilla/opera/linux. Please, what is your configuration ?

I have killed some bugs, new patch available next week. Thanks for you help.

Jej

Hi Jerome

Yep, all browsers. I assume it's a translation mistake in wiki in german version (UTF8)?!? But doesn't matter: (re-)renamed in umlaute it works fine. Have you email address? I can send you the correct file ...DE.php
Our config: MediaWiki 1.5rc4 / PHP 5.0.4 (appache2handler) / MySQL 4.1.1 / all on a linux server. Standard-browsers: IE6 and firefox. (additional in wiki: FCKEditor, Geshi codehighlighting, and other small extensions. That's why I couldn't use your script ;-(. PS: rss works fine.
thanks. huwi

Hi Huwi,

Thanks for the ...DE.php. You can send it to restrict-mediawiki /at/ conseil-recherche-innovation.net

Is it ok now for the link color ?

Jej

Hi J,

I'm having problems displaying a modified quickbar with your extension...I have used the meta.wikimedia.org/wiki/M... extension to alter the site menu, but the php table is somehow being modified by your patch such that the menu is not read correctly. Any suggestions?
-Kyle

Hi K,

I don't think the patch modify anything in the navigation bar code, for version 1.4.x. In branch 1.5 you have to edit the page [[MediaWiki:Sidebar]] so no code is modified by an extension nor the patch. This is only what I understand from the doc :)

Please, give feedback here for other users if you solve this problem.

Jej

Great patch. Is it possible to have all new pages restricted by default when created?

Hi,
i have a problem:
i`ve got it correctly installed and the parameters in the
LocalSettings.php configured, but there is no new tab link or
the new groups are available in the user rights mangement.
i dont know what i have done wrong.

ps.: i am using MediaWiki 1.5rc4 and the patch beta 0.57

could u help me

Not sure why the Modified navigation menu was not working, but the site is running well now. Thanks, Jej

Kyle

Hi Henning,

It seems that nothing works, so maybe you do not browse the correct installation ? Do you have any .rej file after patching ?

Jej

hi there

i just uploaded your restriced stuff, but what I realy miss are the concept of groups to allowing or restricting access to certain pages and not only one group restrict. is there an easy hint to define a group and give them only the read and/or write access?

thanks.
marcel

Hi Jerome,

no i haven`t any *.rej files... do i have to have some of these? if i have *.rej files... then the installation is correct or why do u ask ?

thx for answer :)

greetings henning

Hi Marcel,

"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)."

Then a logged user of the 'restrict' group should see a new tab called 'restrict' (near 'protect').

jej

Hi Henning,

No, *.rej means the patch is not applied. Send your LocalSettings.php to the mail contact, maybe I can investigate a little bit more (remove database params).

jej

ok, i`ve sent you the localsettings.php is there a way to install the patch in windows?

thanks

hey jej

sorry I explained my "wish" may not clear enough (bad English)... so another try:
what I looking for is a function like ACL with this I would be able to say Group "A" has access to Page X and Group "A" and "B" has Access to Page Y. Also with the possibility for Accessrights like read, write, change and/or delete. You know? In my eyes this would need to make all the programming more "dynamics" so that’s not limited to one Group “restrict”, so that I can define groups, add users to those and add them with accessrights to the pages.

Cya
Marcel

Henning: see this note : conseil-recherche-innovat...

Marcel: I agree that mediawiki security model is not very powerful (as it does'nt need it for wikipédia). The patch can't help it. Maybe DokuWiki is for you : wiki.splitbrain.org/wiki:...

jej

Hello,

There seems to be a problem with with newest release of this patch. I used the windows full download of version 0.58 and in the recent changes it only shows changes to the log not changes to unrestricted pages. I would expect the recent changes to hide the changes to restricted pages but not to unrestricted ones.

Any help you can provide on this matter would be appreciated.

Anthony

Holy smokes!
You guys are asking for quite a bit...
Anthony, as long as the page is not viewable, why should it matter that it's in the log? (as in the recommendations, don't name your pages intuitively!)

Kyle

To ensure everybody is happy I introduced a new option for the next version :) (v0.59)

$wgNoRecentChangesRestrict = true to hide restricted pages changes.

jej

I am having a hard time installing this--it tells me the directory does not exist when I attempt the second step?

I am using the version of 1.5.0 released on the 5th of October. I have not modified it in anyway, and it is functioning currently. I added your settings to my localsettings file, but, can not complete the second step of the install so don't know...

Thank you for any help, I really appreciate your dedication to this free application you have created :)

The RSS feeds seem to show the diffs for restricted pages. At least in version 1.5. Is there away around this?

Kyle,

You missed my point. But I figured out what the problem was. It will not show any changes made to any pages if you are logged into the master account. Any other account will show the recent changes of non-restricted pages and will not show the recent changes of Restricted pages. So for the regular users it works just like it is supposed to, just not for the master account user.

Anthony

I'm sorry, I think I misunderstand this. I figured out how to install & it is setup. But, isn't this supposed to allow...chosen users, to modify/see chosen pages? I don't mean to ask for too much or to give a hard time--am just honestly confused :)

it seems right now--like I can restrict a page for ALL who are not on viewrestrict. But what I was hoping was, that I could restrict it to only be accessible by one GROUP or INDIVIDUAL.

Can anyone help? Thanks :)

Does this work with 1.5.1? I tried to patch using restriction-beta-0.58.mediawiki-1.5.0.patch, but it didn't work quite right. I could see the restrict tab, and restrict the pages, and add the restrict and viewrestrict groups to users.

But anonymous users could still view the restricted pages.

I hope to have a bit of time this week-end to update the patch for 1.5.1. Sorry for the delay, that's a really part time job :)

David : "restrict it to only be accessible by one GROUP or INDIVIDUAL". That's the same ! Register the "individual" you mean in the group viewrestrict or restrict. Like an individual can be sysop or not, and some actions are allowed to sysop group or not (and not directly to individual). I use the MediaWiki permission model, not more.

Jej

Can't wait to give it a try as this might just be what I was looking for. Was hoping you got around to finish the update this weekend.

In short, hurry up with that 1.5.1 patch will you ;)

Hi I am able to achieve group wise restriction by placing the following code in function view() of Article.php after $wgOut->setRobotpolicy( 'index,follow' ); line

#--------start copy here ----------#

$dbr =& $this->getDB();

$sql="SELECT ug_group from user_groups where ug_user=" . $this->getUser();
$res = $dbr->query($sql, $fname);
$line = $dbr->fetchObject( $res );
$dbr->freeResult($res);

$contribgrp = $line->ug_group;
$curgrps = $wgUser->getGroups();

if ( !(in_array( $contribgrp, $curgrps ) ) ) {

$relative_url = "index.php";

header("Location: ".$_SERVER['HTTP_HOS... '/\\') . "/".$relative_url);

return;
}
#-------stop copy here ---------#

I'm trying the patch. is there any problem to revert to the official release?
where the restricted status is saved?
bye.
PS: great work

The status of a page is saved in the 'page' table, field 'page_restriction'. I just add ":view=1" for restrict, like MW use move=1 or edit=1 for page protection. So it should not avoid to use the offical release on a modified database.

Any feedback welcome.

Jej

I have a problem, and would appreciate a helpinghand.
The patch runs without any errors. But as soon as I add myself to the group 'restrict' i get:

Fatal error: Call to undefined function: isrestricted() in /usr/local/WWW/www.derechtswinkel.nl/htdocs/intern/wiki/includes/SkinTemplate.php on line 619

Likewise, if I add myself to the groep 'viewrestrict' i get:

Fatal error: Call to undefined function: isrestricted() in /usr/local/WWW/www.derechtswinkel.nl/htdocs/intern/wiki/includes/SkinTemplate.php on line 643

Is there something I overlooked?

To be more precise; I used the patch on a fresh 1.5.2 install, and also tried the pre-patched archive. Both have the same error as a result.

Many thanks in advance !

Really strange... It seems that /include/Title.php is not patched... I tried the pre-patched archive and it works well here. Could you check that line 885 in this file defines the isRestricted() function ?

Jej

Yep, 885 states:

function isRestricted() {
global $wgEnableRestrict;

if ( $wgEnableRestrict == true ) {
$a = $this->getRestrictions("view");
if ( $this->isRegexRestricted() || (!empty($a) && $a[0] == true) ) return true;
}

So that looks allright to me..

Yep, to me too ! isProtected() is defined just above in the same file, is used in SkinTemplate.php and produces no error...

Did you use an old database or a fresh one ?

Jej

When I updated my Wiki to 1.5.2. I used the supplied tools to update my database as well. I haven't had any problems since.

Was there a database-change needed for this extension to work?
Haven't noticed any in the readme's...

No database modification.

Maybe it's a problem with the MW cache. To be sure, try to install a new wiki & database with the 1.5.2 installer, in a different path. If it works well, then switch to your old database params.

Jej

Pages