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

Hi and thanks for your patch.

I'm having trouble with the recent changes page. Pages restricted through the $wgRegexRestrict still shows up in the recent changes even though both the log setting and the recent changes setting ($wgHideRestrictLog, $wgNoRecentChangesRestrict) are true.

Is this as intended or is my setup faulty?

Hello there, great to find a patch for exactly what I need... However, I have downloaded the new 1.5.7 of MW and the patch fails in many places when I try to apply. Could you please have a look and see what needs some updating?... it would be amazingly helpful! Some of the work I’m doing actually does use the IE7 beta browsers and the latest fixes for that browser in the MW 1.5.7 could be quite useful. I am a windows user (so using the ported patch.exe) and yes have changed the patch file through WordPad to fix that CR/LF issue.

The failed outputs are listed below. Thankyou in advance.

patching file `./includes/SpecialExport.php'
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to ./includes/SpecialExport.php.rej

patching file `./languages/LanguageFr.php'
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to ./languages/LanguageFr.php.rej

patching file `./languages/Language.php'
Hunk #1 FAILED at 2128.
1 out of 1 hunk FAILED -- saving rejects to ./languages/Language.php.rej

Luke Stebbing: you're true, the regex restriction is just a small hack to add this feature. I (or you :) can inspect more closely the patch code to see whether it's possible to propagate the same behavior to regex restrictions.

Thansk for your expertise :)

Jej

Joel: same as comment above. It needs some work to make regex restriction working exactly like manual restriction.

Jej

Kevin: keep in touch. I will have a look on 1.5.7. By the way, thanks to announce me this new version :)

Jej

Thanks for updating the package, everything appears to be working great. Fantastic work :-0

Rusian Translation 08.03.2006

#Restrict patch (meta.wikimedia.org/wiki/P...
'restrict' => '??????????',
'restrictthispage' => '?????????? ??????',
'unrestrict' => '?? ????????????',
'unrestrictthispage' => '?? ???????????? ??????',
'restricttitle' => '?????? ? ?????? ?????????',
'restricttext' => '?????? ???????? ?????????? ??? ?????????? ?????????. ??? ????????? ?? ?????? ???? ??????????.',
'restrictedpages' => '???????????? ??????',
'restrictlogpage' => '?????? ???????????',
'restrictlogtext' => '???? ?????? ??????? ? ?????????????. ??. [[{{ns:4}}:???????????? ??????]] ??? ??????? ??????????.',
'restrictedarticle' => '??????????? [[$1]]',
'unrestrictedarticle' => '?? ??????????? [[$1]]',
'restrictsub' => '(?????????? \'[[$1]]\')',
'confirmrestrict' => '??????????? ???????????',
'confirmrestricttext' => '?? ????????????? ??????? ?????????? ??? ???????',
'restrictcomment' => '??????? ??? ???????????',
'unrestrictsub' => '(?? ???????????? \'[[$1]]\')',
'confirmunrestricttext' => '?? ????????????? ??????? ????? ????????????',
'confirmunrestrict' => '??????????? ?????? ???????????',
'unrestrictcomment' => '??????? ?????? ???????????',
'restrictreason' => '(??????? ???????)',
'tooltip-restrict' => '?????????? ??????',
'notallowedtomoverestrictedpagetext' => '??? ??????????? ???? ????????, ?? ?????? ???? ?????? \'restrict\' ??????.',
'restrictedpagespagetext' => '? ???? ?????? ??????? ???????????? ??? ????????? ??????. ',
'regexrestrictedpagespagetext' => '??? ???????? ?????? ??????????????? ?????/???? ????????????? ?????????? ????? ??? ?? ???????????: ',

);

Thank you TOXIN. I will include your translation in the next release.

Jej

How about releasing patch for 1.6Devel

Borgx

Thank you Jerome for what looks like a lot of work. (I had been posting to your talk page on meta.wikimedia.org but this is the place ot be) We're in the process of evaluating MediaWiki, to see whether or not it suits our needs, and one of our needs is page restriction -- just like this patch. :-)

The patching ran smoothly -- it complained it could not find .cvsignore, but that's not a major problem, and it also gave non-empty success messages because a few PHP files in our directories have one or two extra lines (so patch was able to detect the slight offset).

Patching did not change any permissions on any file, so we did not need to fix the permissions after patching.

As soon as we tried to go to the wiki, though, we could not go anywhere; we would get an HTTP 403 Forbidden for any page request. The Apache error log just showed a Denied line but no PHP error output was visible in the log. This has happened whether or not we add the restriction-specific parameters in LocalSettings.php or not, and whether we enabled restriction or not there.

Do you know what the problem could be?

We had a backup and as soon as we rolled out the backup everything went back to normal.

We're using MediaWiki 1.5.7 with the 1.5.7 patch from this page.

D'avance merci,

Thib

borgx: why not... but need still more and more time to do that ! That's the problem :)

Thib: I think the patch itself is not involved in your problem. Maybe the patching process changed some permissions, check again. Please paste a sample of your apache log and a 'ls -la' output.

Jej

Hi Jerome, and thanks for helping.

I saved the output of ls -la on the entire directory structure before applying the patch, and after applying the patch. I compared the outputs with diff, and I verified the following:

* README.restriction-patch was added.
* The only files that are listed differently between the "before" and the "after" are the files that were changed by the patch, because their size has changed.
* None of the files have changed permissions.
* None of the files have changed owners or groups.

Here is a sample (I don't want to page many screenfuls of text):
153,156c156,159
< -rw-r--r-- 1 root root 11920 Mar 7 20:19 SpecialContributions.php
< -rw-r--r-- 1 root root 1120 Mar 7 20:19 SpecialDeadendpages.php
< -rw-r--r-- 1 root root 1998 Mar 7 20:19 SpecialDisambiguations.php
< -rw-r--r-- 1 root root 3154 Mar 7 20:19 SpecialDoubleRedirects.php
---
> -rw-r--r-- 1 root root 12092 Mar 10 00:21 SpecialContributions.php
> -rw-r--r-- 1 root root 1285 Mar 10 00:21 SpecialDeadendpages.php
> -rw-r--r-- 1 root root 2165 Mar 10 00:21 SpecialDisambiguations.php
> -rw-r--r-- 1 root root 3323 Mar 10 00:21 SpecialDoubleRedirects.php

If I access any page, for instance:
example.com/index.php/Mai...

I get:
"Forbidden: You don't have permission to access /index.php/Main_Page on this server."

And the Apache log shows:
[Fri Mar 10 00:32:11 2006] [error] [client 66.159.xxx.xxx] (13)Permission denied: access to /index.php/Main_Page denied

If you insist on me posting a full output of ls -la, I will gladly do it (I didn't today because it's really long).

Encore merci,

Thib

Thib: I think your problem is related to the server side. Check permissions on the index.php file (and on the full directory tree...). I don't think the patch could restrict access at the apache level... Check also any .htaccess file.

Jej

Jérôme:

I applied the patch to an "out of the box" version of MediaWiki and it works just fine. I have also not been able to find anything permission-related or webserver-related that would cause this "Forbidden" jail. Therefore I guess the little changes we made to the PHP code and the little changes made by the patch are in fact messing up the PHP :-) I don't know PHP, so I was hoping I wouldn't have to look inside the files... but I have to,

Merci pour votre excellent travail sur ce patch, il nous sera bien utile.

Regards,

Thib

Hello Jerome, how far are you from adding the ablity to have user level restricted pages? It seems like it wouldn't be too hard to get the patch working so that we could select specfic users from a list that will be allowed to view a particular page.

I was thinking about trying to extend your patch to do this if you you're not going to do it.

Hi Kinnaert,

This needs deeper modifications of mediawiki. I think these features could be part of the main branch of MW, instead of a patch difficult to maintain. We speak about to implement a true ACL and security model in the core of mediawiki, so this could be a concern of the mediawiki team, not only of a patch.

As GPL permits it you can extend the patch ! And we can put your contribution and credit here if you want. Discussions are welcome here to continue on this topic.

Jerome

Thanks for the quick reply,

I think since mediawiki's role is as they have stated to be the wiki appliation for wikipedia etc. and not all things to all people, perhaps like tiki is trying to be, that I can't really see them spending the time to add ACL to their core code. If they would do it, I and a lot of other peoplw would be gratefully surprised, and it would be a gift to the community since they themseleves really don't need this type of functionality.

Having said that, perhaps we should ask them, if they have any plan at all to do anything with ACL's? If not that perhaps a fork of wikimedia might be in order since it seems too many things are having to be changed in the core files? It's getting to be more then a simple extention.

I don't like coding something, if there's already an existing solution that fills the need correctly, it's a true waste of human effort. Do we really need another wiki,cms, or forum system?

Before we talk anymore about turning mediawiki into a robust ACL wiki, does anyone know of any wikis or structued wikis with page level user ACL? I did find one so far, don't know how good it is yet I have to test it out.
wackowiki.com/

Know of any other's with page level ACL's?

We had a discussion about that on the mediawiki developers list : mail.wikipedia.org/piperm...

In fact I don't know what to think :) I use mediawiki for some advantages and mainly because some other engines lack of some features. For example some forbid to include <html>, or use only OldFashionWikiNames to link pages, some lack of category, etc, etc. At the end, we fall back on mediawiki !

To make an ACL patch for mediawiki will be difficult to maintain as the core engine change everytime and it needs deep modifications. That's why I think the core of MW should be modified to allow easily ACL integration even if wikipedia use it only to protect pages or some administrative operations. A good code design for a low level feature is still useful ! To make a fork is not a good idea, it would be better to make a new tool based on special needs not related to encyclopedic needs (not saying that it is a huge work......).

So for now, I wait ! I think that if we need more restrictions it is stupid to use a tool made to be wide open like mediawiki is. Maybe you can have a look on wiki.splitbrain.org/wiki:... and its ACL features.

Hope it helps,
Jerome

I think the "open" community takes things a little too far sometimes...

What do you mean ?!

Hi, I have a few questions if someone would be so kind to answer them, I'd really appreciate it!

Can this patch be applied over an existing install of MediaWiki or do I have to back up the wiki and then install the patch and restore the wiki database?

I downloaded the .patch file, but I'm not sure what to do with it. Is it some script that i can just run? or is there some exe that will know how to unpack/use the restrict patch file? thanks!
-Chan

Jerome,

I've applied the patch (on windows), now it all works alright except the display. instead of having restrict or unrestrict in the tab name, I have "&lt;restrict&gt;" and "&lt;unrestrict&gt;" .same thing for "&lt;Unrestrictrestrict&gt;" and "<confirmrestricttext>"

Any idea ?

forget about it man. When running the patch, it failed to update language.php, that's why. I added the new messages manually and it work fine now. cheers.

I found a pretty bug on the patch for 1.5.7. In Article.php line 1763, 'confirmrestricttext' should be 'confirmunrestricttext'.

BTW, I translated the system messages for this patch into japanese. How can I send it to you?

MediaWiki 1.6.0 released what plans or roadmap you have to patch new version 1.6.0?

If You plane to continue? work please made "ready to use" distributive (already patched).

SHIBUYA: Thanks for this report, I will check that and insert your translation (see "Mailing list and contact" above to mail me or post as a comment here)

Jerome

DEPRECATED, thanks for your help. I have ported the Restriction mod to MediaWiki 1.6.1 now, although I have not tested all the special pages and some functions yet, it appears to be working.

Here are the files you need to install the mod: www.driftsolutions.com/wi...

Just overwrite your existing MW 1.6.1 files with these, and edit your LocalSettings.php as per the instructions @ the top of this page.

As a side benefit, you get the Permissions mod installed as well since I already had it applied before I started porting this.

Let me know if anything doesn't work and I'll try to fix it ASAP.

Hi Indy,

Thanks a lot for this work. I have done a diff and now I check if everything looks good. I didn't know the Permissions mod you mention. I think that's better to separate the two features and leave the choice to apply the one and/or the other.

I will update this blog later and add a credit to you :)

Jerome

Please made already patched wiki 1.6.x distributive, i`m (and perhaps some other readers of this blog) did`t have enough programmer skill to made it self-dependent. Please HELP us!

toxin: see comment 129. Indy Sams made changes for version 1.6.1

I did not verify the integrity of its contrib, so use it at your own risk. And don't forget to thank him :)

Jerome

Please update the patch for the newest version 1.6.3. I just installed mediawiki 1.6.3. Thank you very much!

Steven

Restrict new pages to their author only (or to be able to restrict any page to a single user)

Hava you finished?

DEPRECATED, thanks for your help. I've made a patch from the version 1.6.1 and it is working (hope so) for 1.6.3 as well.

www.fi.muni.cz/~xpavlov/m...

Jan

The patch in comment 135 does not work on 1.6.3. It has errors in the SpecialUserRights.php and does not show the tab for restrict at the top of page.

Anthony: I have the same problem with this contrib... And no answer from the author.

Jerome

well it is not the problem of 135 patch it is the problem of original 129 patch which has the same error witch specialuserright.php

contact Indy Sams

--
Jan

Jan Pavlovic: I was speaking about contrib #129. Sorry for the confusion.

Jerome

Along with the people above, I'd also like to see a working 1.6.3 port of this patch!

Also, how about having this merged upstream?

Sorry for the delay. Two contribs here (#129, #135) propose this patch for 1.6. You can use it for now at your own risk. They are incomplete and I have still a lot of work to do to make the full genuine patch working for 1.6.

For the merge upstream I have to ask to the mw team. I don't think that it's a priority for them to add this feature.

Jerome

DEPRECATED, thanks for your help. I have created a patch for the 1.6.3 version. I make no promises but it works on my server. You can get the patch at www.taac.us/restrict.patc...

And for those that need the complete file you get it here www.taac.us/mediawiki-1.6...

I no very little about php but I can do a little if you find a problem.

Anthony

Well Anthony it seems to be working. Good job!
thanx

Jan

Anthony: thank you. It seems to be a very good base for an official version of the patch. As soon as I have a bit of time I will check your patch and produce a new official release.

For now I put a link in the note. Thanks a lot for this contrib.

Jerome

Would it be possible to post a patch for the linux version as well? Diff on linux doesn't understand how to read the patch file for 1.6.3 (esp. the windows file locations, which I tried fixing using sed, but it still fails to patch even after finding the correct files).

Andy, I am not sure how to fix that little problem. I have only worked with linux for a little while and currently all my machines run Windows (I may get brave and put a version of linux on my laptop). Maybe someone can help you with a windows to linux conversion of the patch.

DEPRECATED, thanks for your help. I have modified the file from Anthony, so it now works fine on Linux!!!

restrict-patch:
www.sendspace.com/file/y5...

The patch that anagy posted doesn't seem to work against 1.6.3, maybe I am doing something wrong? I just copy the patch file into the wiki directory, then do `patch -p0 < restrict.patch`. I get errors such as

patching file ./includes/Article.php
Hunk #1 FAILED at 842.
Hunk #2 FAILED at 1172.
Hunk #3 FAILED at 1203.
Hunk #4 FAILED at 1367.
etc....

Any help with this is greatly appreciated!

I released a patch for MW 1.6.3. Thanks for the different contributors for their help. Please, read the note & changelog. Jerome

Thankyou very much. The new patch for 1.6.3 works perfectly.

Thanks again, Jerome. This feature is the <b>most important</b> MediaWiki extension, and everyone really appreciates it!

Pages