Restrict pages under MediaWiki

Mardi 6 septembre 2005 - Publié par Jérôme Combaz dans Technologie

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

Download the patch for MediaWiki version (patch version) :
- For MediaWiki 1.4.x see this article (deprecated)
- 1.5.8 (beta 0.62) (deprecated)
- 1.6.3 (beta 0.64) (old version, quite stable)
- 1.6.6/1.6.7/1.6.8 (beta 0.72) (new version)
- 1.7.1 : An unstable version (not verified by me) is proposed in a comment below (thanks to JesperZedlitz).
If you have problem to patch (eg. windows users), here is the full pre-patched archive : mediawiki-1.6.8-restriction-patch-beta-0.72.tar.gz (install as usual, but do not forget to enable restriction feature, read the doc above)
Some screenshots (MW 1.4)
MediaWiki home page and the page about 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

Ce bulletin a été publié le Mardi 6 septembre 2005 12:09 et est classé dans Technologie Vous pouvez suivre les réponses à ce bulletin avec le fil RSS 2.0. Vous pouvez aller à la fin et répondre. Les pings ne sont pas admis.

238 réponses à “Restrict pages under MediaWiki”

Jerome Combaz dit :
7 septembre 2005 à 16:09
Please, add your comments below, or subscribe to the mailing list (see above)

Jerome
Chunho Lee dit :
11 septembre 2005 à 11:09
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
Jerome Combaz dit :
11 septembre 2005 à 22:09
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
Chunho Lee dit :
11 septembre 2005 à 22:09
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
Jerome Combaz dit :
12 septembre 2005 à 10:09
arwfff… probably a non-compliant browser ? Did you try to browse with firefox, and what is the visual result ?

jej
Will dit :
13 septembre 2005 à 02:09
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!
Jerome Combaz dit :
13 septembre 2005 à 10:09
Strange… It works perfectly for me for anonymous users. Did you set $wgEnableRestrict = true in LocalSettings.php ?

jej
Will dit :
13 septembre 2005 à 20:09
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.
Will dit :
14 septembre 2005 à 23:09
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.
Jerome Combaz dit :
15 septembre 2005 à 09:09
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
kyle dit :
20 septembre 2005 à 21:09
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
kyle dit :
22 septembre 2005 à 08:09
This extension is fantastic! However, I am now having a problem getting an rss feed for several pages. Any ideas??
Will dit :
22 septembre 2005 à 11:09
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
huwi dit :
22 septembre 2005 à 14:09
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 ä ü etc., I replaced them by ä, ü etc., then it works correct in german version…;-)
Jerome Combaz dit :
22 septembre 2005 à 21:09
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
huwi dit :
27 septembre 2005 à 07:09
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
Jerome Combaz dit :
27 septembre 2005 à 09:09
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
kyle dit :
28 septembre 2005 à 23:09
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
Jerome Combaz dit :
29 septembre 2005 à 10:09
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
Matt dit :
30 septembre 2005 à 18:09
Great patch. Is it possible to have all new pages restricted by default when created?
Henning dit :
5 octobre 2005 à 15:10
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
Kyle dit :
6 octobre 2005 à 09:10
Not sure why the Modified navigation menu was not working, but the site is running well now. Thanks, Jej

Kyle
Jerome Combaz dit :
10 octobre 2005 à 14:10
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
Marcel dit :
11 octobre 2005 à 22:10
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
Henning dit :
12 octobre 2005 à 08:10
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
Jerome Combaz dit :
12 octobre 2005 à 10:10
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
Jerome Combaz dit :
12 octobre 2005 à 10:10
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
Henning dit :
12 octobre 2005 à 11:10
ok, i`ve sent you the localsettings.php is there a way to install the patch in windows?

thanks
Marcel dit :
12 octobre 2005 à 11:10
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
Jerome Combaz dit :
12 octobre 2005 à 12:10
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
Anthony dit :
13 octobre 2005 à 00:10
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
Kyle dit :
14 octobre 2005 à 05:10
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
Jerome Combaz dit :
14 octobre 2005 à 14:10
To ensure everybody is happy I introduced a new option for the next version (v0.59)

$wgNoRecentChangesRestrict = true to hide restricted pages changes.

jej
David dit :
14 octobre 2005 à 22:10
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
Hexi dit :
16 octobre 2005 à 22:10
The RSS feeds seem to show the diffs for restricted pages. At least in version 1.5. Is there away around this?
Anthony dit :
19 octobre 2005 à 12:10
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
David dit :
20 octobre 2005 à 19:10
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
na dit :
27 octobre 2005 à 21:10
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.
Jerome Combaz dit :
28 octobre 2005 à 10:10
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
Zotty dit :
31 octobre 2005 à 11:10
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
Chaitanya dit :
9 novembre 2005 à 08:11
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 ———#
Lenny dit :
10 novembre 2005 à 15:11
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
Jerome Combaz dit :
10 novembre 2005 à 16:11
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
Bzz dit :
22 novembre 2005 à 13:11
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?
Bzz dit :
22 novembre 2005 à 13:11
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 !
Jerome Combaz dit :
22 novembre 2005 à 13:11
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
Bzz dit :
22 novembre 2005 à 13:11
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..
Jerome Combaz dit :
22 novembre 2005 à 14:11
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
Bzz dit :
22 novembre 2005 à 14:11
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…
Jerome Combaz dit :
22 novembre 2005 à 14:11
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
Bzz dit :
22 novembre 2005 à 15:11
Okay… new install works beautifully…
BUT as soon as I switch to my old db it goes wrong again.

I’m open to suggestions…
BTW thanks for your quick response so far.. usually takes weeks for a developer to respond
Jerome Combaz dit :
22 novembre 2005 à 16:11
Try to empty the objectcache and querycache tables. Please give feedback if you find the answer

Jej
Bzz dit :
22 novembre 2005 à 20:11
Nope, that didn’t work either… I’ll try to compare the two databases to see if there’s a difference that might be the cause.
Bzz dit :
22 novembre 2005 à 21:11
Okay… there’s a lot of differences between the two, but nothing out of the ordinary… mostly extra tables which is to be exspected when comparing a empty wiki-db to a full wiki-db.

But now for the funny part; I changed the db params from the old db back to the freshly installed db, which now gives the same error.

I’m out of ideas here… I’ll wrap it up for 2-day and will try again tomorrow (really looking forward to the possibilities of your extension)…
Bzz dit :
23 novembre 2005 à 10:11
I’m not too well at home in php, but in the definition of the isRestricted() function, there’s "getRestrictions("view")", but I can’t find that function defined anywhere in MediaWiki.

Am I Chasing a wild goose here?
Jerome Combaz dit :
23 novembre 2005 à 12:11
Bzz,

getRestrictions() is defined in Title.php (it’s a genuine MW function). It’s still very strange that from two functions defined in the same file, one is well recognized and one produces an error… I cannot understand that !

I updated just now an old wiki from 1.4 to 1.5 with upgrade1_5.php and update.php scripts and no problem was encountered. The patch works, user managment as well… So it’s really difficult to help you more if it is an isolated problem. Try maybe to export/import articles instead of playing with DB convertion.

What I know is that during my tests, the cache often redirect me to an old url pointing to an old installation instead of using the current wiki path, and sometime I was confused as I did not noticed it and my modificaitions did not work. Maybe you encounter the same case, chect that.

Else… good luck

Jej
Bzz dit :
23 novembre 2005 à 15:11
It’s probably a fluke in my db. It’s got 3 (!)wiki installs at the moment. All with different prefixes, but as you pointed out, the caching might be the thing thats bugging.

I’ll just set up a new install (again) and import articles. Luckily there aren’t that many articles yet.
Thnx for your help.
kent1 dit :
25 novembre 2005 à 18:11
Do you believe it will be possible to create different groups and to restrict different pages to these different groups?
In my case, I work with 5 projects but it’s not interesting for me to open 5 different Wikis.
I just want to have 5 groups, 1 for each project.
Excuse me for my poor English (I’m french), I only want that all people understand it…
Thanks for this great patch too…
Jerome Combaz dit :
1 décembre 2005 à 10:12
Hi kent1,

For now not possible. As it is a recurrent request I will have a look. The problem is to implement that feature without too much hack of mediawiki (eg. no database scheme modification).

Then, keep in touch with the blog, and maybe one day you will have it

Jej
NullEnRegexp dit :
8 décembre 2005 à 16:12
Bonjour,
can you give a small regexp example for the array $wgRegexRestrict ?
for example, how can I restrict all pages begining with ‘myBrain:’
Thus [[myBrain:myIdea]] would be restricted.
Thanks
Jerome Combaz dit :
8 décembre 2005 à 16:12
It should be :

$wgRegexRestrict = array( ‘^myBrain:’ );

Is it ?

Jej
Jerome Combaz dit :
8 décembre 2005 à 16:12
Ooops, becareful the Uppercase (Mediawiki uppercase the first letter in the title) :

$wgRegexRestrict = array( ‘^MyBrain:’ );

Jej

ps: it works, tested.
HappyRegexper dit :
8 décembre 2005 à 22:12
Thanks for the example, for the feature, and for this great extension !
Merci!
xshot dit :
10 décembre 2005 à 15:12
Hello,

I tried your patch for page access restriction.I got this message on every page

Warning: Invalid argument supplied for foreach() in /www/htdocs/v147709/wiki/includes/Title.php on line 900

In the User rights management page I can’t find a group named "special"

???
xshot dit :
10 décembre 2005 à 17:12
/include/defaultSettings.php was not patched .. i did it per hand … works fine now
Karen dit :
12 décembre 2005 à 13:12
is it no longer possible to hide the restriction log (in the patch for version 1.5.2)?

// Hide restriction log entries for non-members users
$wgHideRestrictLog = true;

I’ve added this to LocalSettings.php but it makes no difference. People who are not in the viewrestrict group can still see the restriction log.
tof dit :
15 décembre 2005 à 10:12
Hey man, great extension. I’m just wondering, for windows users, you provide the whole mediawiki installation, patched. But in my case, I already have everything installed, and configured, so I can’t just overwrite my files. Any chance you could provide a package with only the files that are concerned by your extension ?

Cheers!
Jerome Combaz dit :
15 décembre 2005 à 12:12
Karen,

ok, the option is back in version 0.6 (for 1.5.3). It was removed with the 1.5.x branch.

Jej
Jerome Combaz dit :
15 décembre 2005 à 12:12
tof,

Here is the list of patched/new files, as you can see in the patch file:

./includes/Article.php
./includes/DefaultSettings.php
./includes/Defines.php
./includes/LogPage.php
./includes/OutputPage.php
./includes/Parser.php
./includes/QueryPage.php
./includes/SearchMySQL.php
./includes/Skin.php
./includes/SkinTemplate.php
./includes/SpecialAllpages.php
./includes/SpecialAncientpages.php
./includes/SpecialBrokenRedirects.php
./includes/SpecialCategories.php
./includes/SpecialContributions.php
./includes/SpecialDeadendpages.php
./includes/SpecialDisambiguations.php
./includes/SpecialDoubleRedirects.php
./includes/SpecialExport.php
./includes/SpecialLog.php
./includes/SpecialLonelypages.php
./includes/SpecialMostlinked.php
./includes/SpecialMovepage.php
./includes/SpecialNewpages.php
./includes/SpecialPage.php
./includes/SpecialPopularpages.php
./includes/SpecialRandompage.php
./includes/SpecialRecentchangeslinked.php
./includes/SpecialRestrictedpages.php
./includes/SpecialShortpages.php
./includes/SpecialUncategorizedpages.php
./includes/SpecialWhatlinkshere.php
./includes/Title.php
./index.php
./languages/LanguageDe.php
./languages/LanguageFr.php
./languages/Language.php
./README.restriction-patch
./skins/monobook/main.css

If you ask me now what are the modifications in these file, please have a look in the patch file

Jej
dechartorn dit :
20 décembre 2005 à 03:12
hi , i need to know — how to install patch on window
Jerome Combaz dit :
20 décembre 2005 à 09:12
You can find a port of the patch command for windows here : unxutils.sourceforge.net. Read also : this comment

No windows here so not tested

Jej
Martin dit :
24 décembre 2005 à 11:12
Hi!

I’m trying to restrict all Special:* pages using the following line within the LocalSettings.php:

$wgRegexRestrict = array("^Special:", "^Special ");

However, this does not work. It works with e.g. Test:* pages.

In fact, I like to restrict the user (or to be more precise a software agent) to grep all pages from the wiki.

Is there a possibility to restrict access to the Special pages?

Best regards

Martin
Jerome Combaz dit :
26 décembre 2005 à 11:12
Mediawiki manages special pages access in a different way, so the restriction does not apply as normal pages.

I think native features could do the job. Look at this page : meta.wikimedia.org/wiki/P… (To prevent a special page from being listed at [[Special:Specialpages]], edit SpecialPage.php and change the relevant entry…)

Jej
Dan East dit :
27 décembre 2005 à 14:12
Regarding message 71 "You can find a port of the patch command for windows here : unxutils.sourceforge.net":

This does work, but first you must re-save the patch file to add in CR/LF pairs, which the win32 version of patch requires.

Open the .patch with WordPad then save to add in the windows style new lines.

Dan East
Jerome Combaz dit :
28 décembre 2005 à 15:12
Thanks for this info.

Jej
edward dit :
2 janvier 2006 à 23:01
Hello,

Some questions about the patch you made.

1) I am working on vs. 1.5.4 of wikimedia. Does your patch also work for this release?

2) Do pictures on a page have the same protection as text?

3) What I want to do is make a site for diving-enthousisast. Every visitor has its own pages which he/she can edit, and the possiblity to upload his underwater-photo’s and dive-statistics (depth, duration, etc). This must not be able to be changed by others (changed by owner only) but must be able to be viewed by everyone.

However, the user may also make pages on ‘dive locations’ and ‘animal species description’ which must be able to be edited by anyone (in the true wiki spirit).

With your patch is it possible to divide the wiki easlily in a ‘personal part’ and a ‘public part’?

Looking forward to your reaction,
Edward Hage
renewe dit :
4 janvier 2006 à 10:01
Hi

Can someone help me?
How can i put New-Users by default to the group "viewrestrict"?

Thx
Jerome Combaz dit :
4 janvier 2006 à 10:01
meta.wikimedia.org/wiki/M…

Jej
Bill Jones dit :
9 janvier 2006 à 21:01
OK, I have read the long discussion about access control lists and all the related materials on MW FAQ site — however I want to know if someone can provide step-by-step instructions to implement this patch BUT substitute student for restrict and studentview for viewrestrict?

IE, I want to expand the category groups. I tried setting up a student group but how can I restrict access to individual classes? IE, UserID studentA is allowed to view and/or edit class IT306 Software Application Programming?

I am sorry if this seems like a duplicate question but after all the reading and testing and troubling shooting I am totally confused.

Any help or insight would be most welcome and appreciated right about now.

Thx/Bill
Denis dit :
13 janvier 2006 à 00:01
Great Patch,

I’m having some difficulties with the wgNoRecentChangesRestrict option.

I’ve noted that it indeed does restrict changes from being listed in the recent changes page, however it doesn’t remove the logs of the fact that the pages have been restricted.

I would like to remove all record of restricted pages from the log so that people can’t view the titles of the pages
Jerome Combaz dit :
13 janvier 2006 à 09:01
It’s quite easy to implement through a new option. I add it to my TODO list.

But if you’ve time to do it you can submit a patch on the patch

Jej
David Van Ronk dit :
17 janvier 2006 à 19:01
Could you please post a update for 1.5.5, I can’t get patch to work on my windows machine.

Thank You
Jerome Combaz dit :
18 janvier 2006 à 10:01
The current patch (0.6) works greatly on 1.5.5. Check your windows

Jej
Jerome Combaz dit :
18 janvier 2006 à 12:01
Denis (comments 80 and 81) : I’am totally stupid, the option already exists and was reintroduced in last version… just add $wgHideRestrictLog = true; in your config.

Becareful with sensible information in page titles. It’s still unadvised.

Jej
Peter dit :
20 janvier 2006 à 05:01
Jerome,

We are using your RESTRICT extension on
MediaWiki: 1.5.0
PHP: 4.3.11 (apache2handler)
MySQL: 3.23.58

and it is working well. I was surprised that RESTRICTED pages are still shown in the list of all pages when this is displayed by a person who is not in the RESTRICT or VIEW RESTRICT group (the contents of the page is not visible to the person.

Is there a setting that hides the titles of RESTRICTED pages? Or is there a way to see a list of all pages that are NOT restricted so people can navigate around these pages.

Thanks for your excellent work.

Peter
Jerome Combaz dit :
20 janvier 2006 à 10:01
Peter: That’s the way it works ! The Special:Allpages page hides restricted titles for normal users and shows it for ‘restrict’ and ‘viewrestrict’ groups. Check that ./includes/SpecialAllpages.php is well patched.

Jej
Alex dit :
23 janvier 2006 à 22:01
I installed the restriction extension, everything works fine. Great work, thank you for your efforts.

One question: I would like to restrict basically all of the pages in my wiki. Do I have to restrict my pages now page by page or is there a shortcut?
Jerome Combaz dit :
24 janvier 2006 à 10:01
Alex: thanks for your comment.

It’s not possible to restrict all existing pages except for new pages ($wgRestrictNewPages option). Generally with this patch we need only some pages restricted. It you need all pages restricted maybe you have to rely on apache authentification or mediawiki features.

Jej
Voltaire dit :
30 janvier 2006 à 20:01
Most of the comments out there pertain to problems with this customization. I got it to work but by taking the list of files that Jerome listed and just overwriting them in the file server.

Thanks again.

Merci Jerome! Ca marche tres bien!
Voltaire
Jerome Combaz dit :
31 janvier 2006 à 09:01
Thank you

jej
Chris dit :
31 janvier 2006 à 15:01
Jerome,

Thank you very much for the patch! It works exactly the way I needed it to.
Jerome Combaz dit :
31 janvier 2006 à 15:01
Thank you too !

A nice day today

Jej
Bernd dit :
1 février 2006 à 12:02
Hello,
after I have restricted an article I would expect a view=1 in the page table. The user are still allowed to view the acticle, but not allowed to edit them.
A would like that they not able to view the article.
Bernd
ahru dit :
11 février 2006 à 07:02
I encountered the following error upon installing the patch from the pre-patched archive:
Deny from all
Fatal error: Class languageutf8: Cannot inherit from undefined class language in /home/content/l/e/h/lehommenet/html/zenru/wiki/languages/LanguageUtf8.php on line 38
Jerome Combaz dit :
13 février 2006 à 11:02
Sorry, small mistake in LanguageSv.php. Add a comma at the end of the line 892. Patch updated.

Jej
Jonathan dit :
21 février 2006 à 10:02
Hi,

i installed the patch with mediawiki 1.5.0. Now i’m using 1.5.6 without any patches. How do i remove the rest of the patch (there is still the ‘button’ restrict page, and the recent changes-pages doesn’t work anymore….)

Jonathan
Jerome Combaz dit :
21 février 2006 à 10:02
Just install 1.5.6 in a new directory…

Or replace all files modified (see comment 69) by the patch with the files from 1.5.6 version.

Jej
Luke Stebbing dit :
25 février 2006 à 07:02
Hi,
I installed the patch and almost everything is working great, but pages that were restricted with a regular expression don’t seem to be treated quite the same as pages that were directly marked as restricted (with action=restrict). For example:
$wgRegexRestrict = array("^A:");

pages:
B <- "testphrase"
Restricted:B <- "testphrase"
A:B <- "testphrase"

Say B was set to restricted with the "restrict" tab. Of course, the other two pages already show up as restricted pages.

If I search for "testphrase" as a user who doesn’t have the "viewrestrict" right, the line in B will not show up, but the lines in Restricted:B and A:B will. I can’t click on those pages, but I can still figure out lots of the content by guessing different words.

Looking in the database, B has "edit=:move=:view=1" in its page_restrictions field, but Restricted:B and A:B don’t. If I force that field to be added by putting …/A:B?action=restrict in the address bar, then the restriction works and I can no longer search for the phrase.
Morrissimo dit :
28 février 2006 à 17:02
What I’ve seen so far of this addon I love — but I can’t quite make it do what I was trying to do. Hopefully you guys can set me straight.

1) I’d like to restrict User pages to be editable only by their User — I’ve figured out how to do this.
2) I’d like User pages to be *viewable* by anyone. — I can’t figure out how to do this.

Can anyone help me figure out how to set up this addon to do both 1) and 2) at the same time? Thanks in advance…
Joel dit :
1 mars 2006 à 12:03
Hello, thanks for your patch.

I’m having trouble with recent changes. I have set $wgNoRecentChangesRestrict = true; but creation of pages restricted by $wgRegexRestrict still shows up in the recent changes log. Is this as inteded or is my setup faulty?

regards
Joel
Joel dit :
1 mars 2006 à 12:03
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?
Kevin dit :
5 mars 2006 à 08:03
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
Jerome Combaz dit :
5 mars 2006 à 13:03
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
Jerome Combaz dit :
5 mars 2006 à 20:03
Joel: same as comment above. It needs some work to make regex restriction working exactly like manual restriction.

Jej
Jerome Combaz dit :
5 mars 2006 à 20:03
Kevin: keep in touch. I will have a look on 1.5.7. By the way, thanks to announce me this new version

Jej
Kevin dit :
6 mars 2006 à 16:03
Thanks for updating the package, everything appears to be working great. Fantastic work :-0
T O X I N dit :
8 mars 2006 à 13:03
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’ => ‘Все названия статей удовлетворяющих этому/этим семантическим выражениям будут так же ограниченны: ‘,

);
Jerome Combaz dit :
8 mars 2006 à 14:03
Thank you TOXIN. I will include your translation in the next release.

Jej
borgx dit :
9 mars 2006 à 09:03
How about releasing patch for 1.6Devel

Borgx
Thib dit :
9 mars 2006 à 11:03
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
Jerome Combaz dit :
9 mars 2006 à 11:03
borgx: why not… but need still more and more time to do that ! That’s the problem
Jerome Combaz dit :
9 mars 2006 à 11:03
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
Thib dit :
10 mars 2006 à 09:03
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
Jerome Combaz dit :
10 mars 2006 à 09:03
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
Thib dit :
13 mars 2006 à 20:03
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
kinnaert dit :
13 mars 2006 à 22:03
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.
Jerome Combaz dit :
14 mars 2006 à 10:03
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
Kinnaert dit :
14 mars 2006 à 12:03
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?
Jerome Combaz dit :
14 mars 2006 à 15:03
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
kinnaert dit :
14 mars 2006 à 16:03
I think the "open" community takes things a little too far sometimes…
Jerome Combaz dit :
14 mars 2006 à 17:03
What do you mean ?!
Chan Sarinyamas dit :
24 mars 2006 à 22:03
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
tof dit :
31 mars 2006 à 08:03
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 "<restrict>" and "<unrestrict>" .same thing for "<Unrestrictrestrict>" and "<confirmrestricttext>"

Any idea ?
tof dit :
3 avril 2006 à 02:04
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.
SHIBUYA K. dit :
5 avril 2006 à 08:04
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?
T O X I N dit :
6 avril 2006 à 08:04
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).
Jerome Combaz dit :
6 avril 2006 à 09:04
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
Indy Sams dit :
10 avril 2006 à 02:04
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: http://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.
Jerome Combaz dit :
10 avril 2006 à 18:04
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
T O X I N dit :
11 avril 2006 à 08:04
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!
Jerome Combaz dit :
11 avril 2006 à 09:04
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
void dit :
13 avril 2006 à 01:04
Please update the patch for the newest version 1.6.3. I just installed mediawiki 1.6.3. Thank you very much!

Steven
Pinchao Si dit :
14 avril 2006 à 09:04
Restrict new pages to their author only (or to be able to restrict any page to a single user)

Hava you finished?
Jan Pavlovic dit :
14 avril 2006 à 12:04
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.

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

Jan
Anthony dit :
15 avril 2006 à 19:04
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.
Jerome Combaz dit :
16 avril 2006 à 19:04
Anthony: I have the same problem with this contrib… And no answer from the author.

Jerome
Jan Pavlovic dit :
18 avril 2006 à 00:04
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
Jerome Combaz dit :
18 avril 2006 à 09:04
Jan Pavlovic: I was speaking about contrib #129. Sorry for the confusion.

Jerome
Chris Evich dit :
20 avril 2006 à 13:04
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?
Jerome Combaz dit :
20 avril 2006 à 14:04
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
Anthony dit :
20 avril 2006 à 21:04
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 http://www.taac.us/restrict.patc...

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

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

Anthony
Jan Pavlovic dit :
21 avril 2006 à 03:04
Well Anthony it seems to be working. Good job!
thanx

Jan
Jerome Combaz dit :
21 avril 2006 à 09:04
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
Andy dit :
21 avril 2006 à 20:04
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).
Anthony dit :
22 avril 2006 à 04:04
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.
anagy dit :
23 avril 2006 à 23:04
DEPRECATED, thanks for your help.

I have modified the file from Anthony, so it now works fine on Linux!!!

restrict-patch:
http://www.sendspace.com/file/y5...
Andy dit :
24 avril 2006 à 19:04
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!
Jerome Combaz dit :
25 avril 2006 à 09:04
I released a patch for MW 1.6.3. Thanks for the different contributors for their help. Please, read the note & changelog.

Jerome
andy dit :
25 avril 2006 à 21:04
Thankyou very much. The new patch for 1.6.3 works perfectly.
Kyle dit :
29 avril 2006 à 18:04
Thanks again, Jerome. This feature is the most important MediaWiki extension, and everyone really appreciates it!
Nicholas E. May dit :
30 avril 2006 à 22:04
When I followed the instructions found on this page, the patch did not work. However, when I followed the instructions in the READEME that came with the patch (1.6.3), things worked fine. This page told me to add the code for LocalSettings.php to the end of the file, whereas the READEME told me to add it right after require_once( "includes/DefaultSettings.php" );

Point being, you might want to edit this page a bit to specify the correct location for the code. Ditto for the MediaWiki page about the patch.
Tony dit :
1 mai 2006 à 04:05
Can someone tell me how I might restrict a Category?
Jerome Combaz dit :
1 mai 2006 à 14:05
Nicholas E. May: I specified to place the config after the "require" because some novice users reported bug after putting the config at the most top of the LocalSettings.php file. I can clarify a bit more, but I don’t think your problem is related to that.

Jerome
Tony dit :
1 mai 2006 à 14:05
I think I found a bug. When I create a page and manually restrict it, the page does not show up in the search results.

When I create a page that has a title that matches this $wgRegexRestrict = array("^Secure:", "^Secret "), it is properly restricted, but it shows up in search results. These results display quite a bit of the actual text on the page.
T O X I N dit :
1 mai 2006 à 21:05
I have such eror when i click on Category Link

«1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘WHERE cl_to = `page`.page_title AND `page`.page_restrictions NOT LIKE ‘%view=1% » at line 7 (localhost)».
Jerome Combaz dit :
1 mai 2006 à 21:05
Tony: for now it’s not a bug, just a lack of the patch.

Regex restriction is a "light solution" to restrict pages based on their title. The restriction works only when accessing the page. It would add cpu load to check the regex restriction everywhere it’s necessary (actually many checks are made with SQL, I don’t know if we have the same regex in SQL and what could be the cpu overload).

Jerome
Jerome Combaz dit :
1 mai 2006 à 21:05
Hi T O X I N,

Thanks for the report. You have a new patch to download and test (v0.64). It includes as well the hebrew translation (see changelog)

Jerome
Yong dit :
4 mai 2006 à 16:05
There is a problem in the latest patch on the Special:Recentchangeslinked page. There is SQL error if restriction is enabled. I think the query should also join with the pages table.

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "wfSpecialRecentchangeslinked". MySQL returned error "1054: Unknown column ‘rc_title’ in ‘on clause’ (localhost)".
Yong dit :
4 mai 2006 à 16:05
Wrong SQL error in the last post, it should be:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "wfSpecialRecentchangeslinked". MySQL returned error "1054: Unknown column ‘page_restrictions’ in ‘where clause’ (localhost)".
Anthony dit :
5 mai 2006 à 08:05
Just for those that wondered…0.64 patch works with 1.6.5. I have it running just fine at my site.

YONG…I cannot duplicate the error you describe. Both 1.6.3 and 1.6.5 with patch 0.64 does not give this error. I would suggest that you rename your LocalSettings.php and rerun the installer and see if that does not fix your problem. Don’t forget to add the restrict data back into LocalSettings.php when you are done!
T O X I N dit :
5 mai 2006 à 19:05
Anybody please made Wiki 1.6.5 patched version
Anthony dit :
15 mai 2006 à 03:05
You can get the files already patched at http://www.taac.us/mediawiki-1.6...

If you have any problems let me know and I will see what I can do.

Anthony
ahru dit :
15 mai 2006 à 04:05
thanx for the patched 1.6.5 anthony.
Ency dit :
16 mai 2006 à 00:05
#Polish translation by #Restrict patch ( href="http://meta.wikimedia.org/wiki/Page_access_restriction_with_MediaWiki)" title="http://meta.wikimedia.org/wiki/Page_access_restriction_with_MediaWiki)">meta.wikimedia.org/wiki/P…
=> ‘Zastrzeżenie’,
=> ‘Zastrzeżenie tej strony’,
=> ‘Zdjęcie zastrzeżenia’,
=> ‘Zdjęcie zastrzeżenia tej strony’,
=> ‘Strona zastrzeżona’,
=> ‘Ta strona jest zastrzeżona. Aby mieć do niej wgląd musisz być w grupie użytkowników \’restrict\’ lub \’viewrestrict\’.',
=> ‘Strony zastrzeżone’,
=> ‘Dziennik (log) zastrzeżeń’,
=> ‘Poniżej jest lista zastrzeżeń stron. Zobacz [[{{ns:4}}:Strony zastrzeżone]] z dodatkowymi informacjami.’,
=> ‘zastrzeżono [[$1]]’,
=> ‘zdjęto zastrzeżenie [[$1]]’,
=> ‘(Zastrzeżenie \’[[$1]]\’)',
=> ‘Potwierdź zastrzeżenie’,
=> ‘Czy naprawdę chcesz zastrzec tę stronę?’,
=> ‘Powod zastrzeżenia’,
=> ‘(Zdjęcie zastrzeżenia \’[[$1]]\’)',
=> ‘Czy naprawdę chcesz zdjąć zastrzeżenie tej stronę?’,
=> ‘Potwierdź zdjęcie zastrzeżenia’,
=> ‘Powód zdjęcia zastrzeżenia’,
=> ‘(podaj powód)’,
=> ‘Zastrzeż tę stronę’,
ctedpagetext’ => ‘Przeniesienie tej strony mogą wykonać tylko użytkownicy z grupy \’restrict\’.',
=> ‘Ta strona podaje listę wszystkich zastrzeżonych stron tej wiki.’,
=> ‘Zastrzeżenie dotyczy wszytkich tytułów artykułów spełniających warunki regularnych wyrażeń: ‘,
T dit :
20 mai 2006 à 07:05
Please, Jerome, take note of the workaround to access protected pages found in meta.wikimedia.org/wiki/T…

I supposed you would see it here sooner than there
Anthony dit :
20 mai 2006 à 21:05
I cannot reproduce the bug in comment 165. Not sure what version he is using but in version 1.6.5 it is fixed.

Anthony
Jerome Combaz dit :
22 mai 2006 à 10:05
No problem with redirections, I confirm…

Jerome
Cipher dit :
22 mai 2006 à 23:05
I have used your pre-patched archive ( mediawiki-1.6.3-restriction-patch-beta-0.64.tar.gz) for seting up my wiki. But I can’t find the ‘restrict’ or the ‘viewrestrict’ group in the ‘User rights management’ page. Do I need to make these groups on my own? If so, do I just put
" $wgGroupPermissions['restrict']['restrict']= true; " in ‘DefaultSettings.php’?

Thank you for your help.

Cipher
Jerome Combaz dit :
23 mai 2006 à 09:05
Cipher:

As written above near the archive link : "(do not forget to enable restriction feature, read the doc above)" (see section ‘Configure’).

Jerome
Cipher dit :
23 mai 2006 à 19:05
I copied and pasted the configure section into LocalSettings.php already. But the groups did not show up in the user rights page. Which is why I am confused.

Thanks

Cipher
Anthony dit :
24 mai 2006 à 08:05
I have created a patch file for MW 1.6.6 with the Polish Translation in comment 164 included. You can find the patch file at http://www.taac.us/restrict/rest...

Keep in mind that I use Windows XP so there is no guarentee that it will work with Linux. There seems to be a way to convert the patch file to work with linux and if someone can let me know how that would be great.

For those that need the already patched files, they are at http://www.taac.us/restrict/medi...

As always, if there is any problems, feel free to let me know.

Anthony
Jerome Combaz dit :
24 mai 2006 à 09:05
Thanks Anthony for this contrib.

I will publish soon a new version of the patch with a different way to manage restricted pages (no SQL modification, and regex restricted pages are treated exactly like the manually restricted pages).

Jerome
Jerome Combaz dit :
24 mai 2006 à 09:05
Cipher: Did you log in as a sysop ?

Jerome
Cipher dit :
24 mai 2006 à 19:05
Yes I did. I even tried the admin log in. But nothing seems to be working. I also looked into the ‘DefaultSettings.php’ file where the groups should be at ( I think ), but there is nothing regarding restriction groups.

^^;;

Cipher
Jerome Combaz dit :
24 mai 2006 à 22:05
Cipher: strange… nothing concerning groups has to be added in the DefaultSettings.php. Send me this file by mail so I can investigate more (remove db passwd ).

Jerome
Cipher dit :
25 mai 2006 à 04:05
‘DefaultSettings.php’ doesn’t have password for the database. Is this the file you want?

Also, where can I find your e-mail address? ^^;;

Thanks
Cipher
Jerome Combaz dit :
25 mai 2006 à 19:05
Cipher: oups sorry, I mean the LocalSettings.php. Nothing to add or modify in the DefaultSettings.php (if well patched).

Jerome
Cipher dit :
25 mai 2006 à 20:05
Ok, I send the LocalSettings.php file of my wiki to restrict-mediawiki-list-subscribe@conseil-recherche-innovation.net.

I hope this is the right address. ^^;;

Thank you very much

Cipher
Anthony dit :
25 mai 2006 à 22:05
This is a rerelease to to a bug in the previous patch and zip. Please upgrade if you used the patch or zip from comment 171. Sorry!

I have created a patch file for MW 1.6.6 with the Polish Translation in comment 164 included. You can find the patch file at http://www.taac.us/restrict/restriction-beta-0.65.mediawiki-1.6.6.patch

Keep in mind that I use Windows XP so there is no guarentee that it will work with Linux. There seems to be a way to convert the patch file to work with linux and if someone can let me know how that would be great.

For those that need the already patched files, they are at http://www.taac.us/restrict/mediawiki-1.6.6.zip

As always, if there is any problems, feel free to let me know.

Anthony
Jake dit :
27 mai 2006 à 00:05
I installed the patch 0.62 for 1.5.8 on my media wiki version 1.5.5

It seems to work very well, except there is some funny charators on the tab and title’s of restrcted pages…

On the tab of a user in the groups viewrestrict and restrict
<unrestrict>
<restrict>

From a restricted page as user not in "viewresrict"
<restricttitle>
<restricttext>

Is there any fix for this? other than that it works fine. The problom is I dont know how to upgrade my wiki from 1.5.5 to 1.6.x to try your new patch… I suppose I’ll look in to upgrading it and trying the new patch. But if there is a simple fix for the above problom that would be killer..

Thanks for this great media wiki extension…

Jake
Jake dit :
27 mai 2006 à 00:05
Of course after I ask the questions I find the answer from above…

Thanks "tof"…

just add the following to the languages/Language.php

#Restrict patch (meta.wikimedia.org/wiki/P…
#
‘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 : ‘,
Jerome Combaz dit :
27 mai 2006 à 10:05
Cipher: please read carrefuly ! the contact address is restrict-mediawiki/at/conseil-recherche-innovation.net (your posted on the mailing list subscription

Jerome
EJG dit :
29 mai 2006 à 04:05
can someone please explain how to install this? i cant get it to work
Cipher dit :
1 juin 2006 à 21:06
Hi Jerome:

Sorry, my RL has been a real pain for a while.. -_-;; .. and as for the contact, I tried to find it.. But I can’t make heads and tails on the contact page. ^^;; I can’t read French.

Can you be a little clearer on where your e-mail address is? Thank you very much.

Cipher
Jerome Combaz dit :
2 juin 2006 à 10:06
Hi Cipher:

I cannot be more explicit !! See above in this blog note (title "Mailing list and contact") or in comment #182 or read this : "To contact me : restrict-mediawiki/at/conseil-recherche-innovation.net"

Replace /at/ with @ of course !!

Cheers, Jerome
Cipher dit :
6 juin 2006 à 04:06
O.o.. ops.. my bad.. ^^;; yea. I just send it to that address.

Thank you very much for helping me,

Cipher
Owen dit :
6 juin 2006 à 17:06
I am also having the same problem as Yong, above:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "wfSpecialRecentchangeslinked". MySQL returned error "1054: Unknown column ‘page_restrictions’ in ‘where clause’ (localhost)".

This seems to be related to not having FROM `page` in the MySQL query, only `pagelinks` and `recentchanges`?

Running 0.64 patch, against Mediawiki 1.6.6
Jerome Combaz dit :
7 juin 2006 à 10:06
Hi all,

I published a new version of the patch, with many changes (see changelog). Problems with sql requests should be minimised. Please test this version and give feedbacks.

Thank you for all the comments and contributions received until now. It’s a good motivation for me!

Jerome
mrproper dit :
9 juin 2006 à 10:06
Great work Jerome!

I am forced to use the prepatched archived installation, and yet I have so many changes since the previous (1.5.8) version that I will spend some serious time getting everything back to a working environment. This is one of the most useful patches for MW I ever used.

Happy coding!
Jerome Combaz dit :
9 juin 2006 à 10:06
Hi mrproper,

Thanks. I know many people use previous versions of MW, but it si difficult to adapt the patch for the different versions. I (we) should do it but in the actual context it impossible for me due to time considerations.

Maybe should we to switch to a more confortable platform than this blog note!

Jerome
Mauro dit :
9 juin 2006 à 18:06
Hi,

your patch is very nice… but…work only with group "restrict".
About "Creating Restricted Areas / Virtual Wiki spaces" is there some extension? I want to create a private area "Area A" for the group A… after i want to create a private area "Area B" for the group B… after i vant create a group C that have access to "Area A" and "Area B".

Some help…
Shaun dit :
14 juin 2006 à 15:06
Is there anyway to restrict a page to a different group other then the restrict and viewrestrict groups?
Jaime dit :
20 juin 2006 à 03:06
I was patching mediawiki 1.6.7 and i got the following error:

patching file ./includes/DefaultSettings.php
Hunk #1 FAILED at 1933.
1 out of 1 hunk FAILED — saving rejects to file ./includes/DefaultSettings.php.rej

I went back and noticed there were two mentions of it for earlier versions but no-one seems to have come across it in the latest version. Is there anything i can do about this error? If you need me to forward any information I’m more than willing.

Thanks for any help you can give.

Regards,
Jaime
Tom dit :
26 juin 2006 à 20:06
Many thanks for this excellent patch.

Like other users, I’d like to be able to make different restrictions for different groups.
Anthony dit :
8 juillet 2006 à 06:07
Just a bump to let you know that 1.7.0 is out now. I tried to work on it but ran into problems beyond my knowledge so if anyone else wants to take a stab at it, that would be great.

Anthony
Jerome Combaz dit :
10 juillet 2006 à 11:07
Thanks Anthony. I read that on Mediawiki-l but no time to try the patch. I will have a look now. 
 
Jerome
Owen dit :
11 juillet 2006 à 23:07
I’d like to add my thanks too for this patch; it’s very useful.

My wishlist for the patch:
* different restrictions for different groups (seems this is a popular request)
* some level of LDAP integration whereby restricted page access gould be checked agains an LDAP group
Jerome Combaz dit :
12 juillet 2006 à 11:07
Thanks Owen. I note your requests. 
 
But for now I have to fight with the 26 rejected hunks because of the new MW version… 
 
Jerome
Owen dit :
12 juillet 2006 à 23:07
OK, understood. By the way, I think I noticed a bug in the patch; in Article::updateRestrictions, the line

$restrictions .= ":view=1";

should be

$flat .= ":view=1";

… I think

Thanks again for your patch!

Owen
Owen dit :
13 juillet 2006 à 01:07
Another bug, I think. In Skin.php, function bottomLinks(), replace

if( $wgEnableRestrict == true && $wgUser->isAllowed(‘viewrestrict’)) { $s .= $sep . $this->restrictThisPage(); }

with

if( $wgEnableRestrict == true && $wgUser->isAllowed(‘restrict’)) { $s .= $sep . $this->restrictThisPage(); }

All the best,

Owen
Jerome Combaz dit :
13 juillet 2006 à 10:07
Thanks Owen. 
 
You are right. These bugs were included during a big update of MW. Sorry for that. A new version (0.71) is online. 
 
I think that early or late I will not be able to follow all the MW changes and adapt the patch in time. I don’t understand why MW does not provide a true API for ACL concerns. 
 
Jerome
Andy dit :
13 juillet 2006 à 20:07
Did anyone ever get all of the bugs worked out of MW 1.7.1? I’m running into all sorts of problems after updating. I think for now I’ll just stick with 1.6.7
Jerome Combaz dit :
17 juillet 2006 à 09:07
Hi Andy and all, 
 
The patch doesn’t work for 1.7.1. As you see many modifications are rejected when patching, due to MW changes. 
 
I think I will not update this patch anymore. I am thinking about an extension, what is more stable when MW updates. <!–I spoke with Petr Andreev, author of the NamespacePermissions Extension. We will join our efforts to provide a nice restriction extension which combines the features and ideas of this patch and its extension.–> 
I cannot give any date for the first release, just subscribe to the mailing list to keep in touch (<a href= »mailto:restrict-mediawiki-list-subscribe@conseil-recherche-innovation.net »>restrict-mediawiki-list-subscribe@conseil-recherche-innovation.net</a>) 
 
Read you, 
Jerome
Barry dit :
18 juillet 2006 à 18:07
I have subscribed to your email list and am happy to help. I can see there are several things you could do to make the patch more maintainable. Could you post a summary of what you plan to do? Perhaps on the Wikimedia page so everyone can see?
DonJ dit :
19 juillet 2006 à 03:07
RE:
I think I will not update this patch anymore. I am thinking about an extension, what is more stable when MW updates. I spoke with Petr Andreev, author of the NamespacePermissions Extension. We will join our efforts to provide a nice restriction extension which combines the features and ideas of this patch and its extension.

I think that’s a great idea. Good Luck.
Maybe some sort of ACL model??

Regards,
Borgx dit :
19 juillet 2006 à 04:07
I agree that this discussion should be moved to Wikimedia site. By the way, running rebuildall.php will removes all links to (special:whatlinkshere) templates. I think that is a bug. (mw 1.6.7 / patch 0.71)
pfelsted dit :
26 juillet 2006 à 07:07
I have made a patch to this patch for restricting access to menu items in the MediaWiki:Sidebar. I have posted it on the bandit-project web site:
http://www.bandit-project.org/in...

It is only like 20 lines of code. Enjoy.
ciza dit :
31 juillet 2006 à 16:07
Hi.I would like to translate restriction messages to Czech language. I have got a problem with it. I ve tried to edit a /languages/MessagesCs.php and put text bellow to the end of that file. If i set the czech language in my user preferences I still cant see my czech restriction messages. Where is a problem? Could you help me?

Thanks

#Restrict patch (meta.wikimedia.org/wiki/P…
‘restrict’ => ‘Omezit přístup’,
‘restrictthispage’ => ‘Omezit přístup na tuto stránku’,
‘unrestrict’ => ‘Zveřejnit’,
‘unrestrictthispage’ => ‘Zveřejnit tuto stránku’,
‘restricttitle’ => ‘Stránka s omezeným přístupem’,
‘restricttext’ => ‘Na tuto stránku je omezený přístup. Zřejmě nemáte oprávnění k jejímu čtení’,
‘restrictedpages’ => ‘Stránky s omezeným přístupem’,
‘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’ => ‘Potvrzení omezení přístupu’,
‘confirmrestricttext’ => ‘Opravdu chcete omezit přístup k této stránce?’,
‘restrictcomment’ => ‘Důvod pro omezení’,
‘unrestrictsub’ => ‘(Unrestrict \’[[$1]]\’)',
‘confirmunrestricttext’ => ‘Opravdu chcete zveřejnit tuto stránku?’,
‘confirmunrestrict’ => ‘Potvrzení zveřejnění’,
‘unrestrictcomment’ => ‘Důvod zveřejnění’,
‘restrictreason’ => ‘(give a reason)’,
‘tooltip-restrict’ => ‘Omezit přístup’,
‘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 : ‘,
FIZ dit :
31 août 2006 à 11:08
Hello,

I just tryed this patch with mediawiki 1.6.8 and it seems to work. The only "Problem" I have: the [[Special:Restrictedpages]] doesn’t list any pages. But I guess I can live with that by now

Good job
Jake dit :
31 août 2006 à 19:08
I too have the same problem. The patch works fine but the Special:Restrictedpages page does not even load, HTML Page Source is empty.

I’m using mediawiki 1.6.8 and patch version 0.71…

I’m not sure if the page ever work as I just noticed it does not right now…
Jake dit :
31 août 2006 à 20:08
RE:
208. Le jeudi 31 août 2006 à 11h20, par FIZ

Hello,

I just tryed this patch with mediawiki 1.6.8 and it seems to work. The only "Problem" I have: the [[Special:Restrictedpages]] doesn’t list any pages. But I guess I can live with that by now

Good job

209. Le jeudi 31 août 2006 à 19h36, par Jake

I too have the same problem. The patch works fine but the Special:Restrictedpages page does not even load, HTML Page Source is empty.

I’m using mediawiki 1.6.8 and patch version 0.71…

I’m not sure if the page ever work as I just noticed it does not right now…
END RE

Hey I figured it out… I think the patch did not create mediawikisintall/includes/SpecialRestrictedpages.php… if you open the patch file and search for "SpecialRest" you can see where the page start from line 862 "+<?php" and ends at line 941 "+?>" copy all those lines into WikiInstallDir/includes/SpecialRestrictpages.php but you have to remove all of the "+" signs at the start of each line…

Good luck FIZ

Jake
Jerome Combaz dit :
1 septembre 2006 à 11:09
I do not have any problem regarding the Special:Restrictedpages on my running version. Download and test the full archive. 
 
Jerome
hax dit :
11 septembre 2006 à 09:09
Does anyone knows something about a possible extension for Mediawiki 1.7 because i realy Need it for my job! thank’s for response.
Lusiano dit :
13 septembre 2006 à 08:09
Does anyone know how to restrict special pages?

Thank You
Jerome Combaz dit :
14 septembre 2006 à 15:09
Have a look here : <a href= »http://meta.wikimedia.org/wiki/Preventing_Access#Preventing_access_to_some_SpecialPages » title= »http://meta.wikimedia.org/wiki/Preventing_Access#Preventing_access_to_some_SpecialPages »>meta.wikimedia.org/wiki/P…</a> 
 
Jerome
hax dit :
18 septembre 2006 à 10:09
does it’s possible to create new group? and restrict acces to certain pages only for this group?
JesperZedlitz dit :
6 octobre 2006 à 10:10
I have adjusted the patch to work with MediaWiki 1.7.1

It is not very well tested. So it is maybe not a good idea to use it in a productive environment without extensive testing.

http://www.zedlitz.de/restrictio...
Jerome Combaz dit :
6 octobre 2006 à 16:10
Thanks you very much, JesperZedlitz. I will have a look on your work and maybe publish this version will on the blog. 
 
Jerome
P Coltharp dit :
13 octobre 2006 à 15:10
My wishes are to be able to restrict users from editing other user’s User Pages. Is this possible with this patch? I am fustrated ans I can not find the correct combination of settings, alone to do this with the patch. PLease help. I am using MediaWiki 1.6.8.
Jerome Combaz dit :
16 octobre 2006 à 15:10
@Vaddy : avez-vous essayé la procédure décrite ici ? sous debian probablement aucun problème. Le paquet ‘patch’ doit cependant être installé. 
 
Jerome
Vaddy dit :
16 octobre 2006 à 14:10
Pour un newby très intéressé, une question qui vous paraîtra débile, et pourtant !
– comment lancer le patch sur Debian ?
George dit :
22 octobre 2006 à 00:10
How do we apply the patch?

At the top of this page there is something that says "Apply patch" followed by some ambiguous code. Is this some sort of command line instructions we are to deploy?

Isn’t there a way to replace one file with another by FTP, or to revise the file by manually replacing text?
Pupster dit :
24 octobre 2006 à 20:10
To apply the patch, upload the patch to your directory where mediawiki lives, then run the command

patch -p0 < restriction-version.mediawiki-version.patch

for example

patch -p0 < restriction-beta-0.8.mediawiki-1.7.1.patch
Jerome Combaz dit :
25 octobre 2006 à 09:10
Thanks Pupster. 
 
Another way is to download the full patched version of mediawiki. A link is provided above in the post. 
 
Jerome
Cedric dit :
28 octobre 2006 à 11:10
Hi. I applied your patch to my MW 1.5.3, and this is THE feature I needed. I mean, nothing more, nothing less. Really great thanks. However… I’m about to move to 1.8. In the ideal world, I would like this patch to be applied again on 1.8, and with my database still "remembering" all pages restricted before. Is it possible, forseen, forseenable?… This "remembering" question might be silly, but I have no clue how this works in reality. I just subscribed to the mailing list. I hope to have more news then. Thanks again.

Cedric
Syn dit :
31 octobre 2006 à 17:10
I’m really confused. A friend of mine has me working on his wiki, version 1.6.8 and I really want to install this patch. I downloaded the restriction-beta-0.72.mediawiki-1.6.8.patch and have no idea where to install it in the wiki and where are you suppose to run the command

patch -p0 < restriction-version.mediawiki-version.patch???

Also, we already have pages up and users using our wiki. Can we still apply this patch?

In short, I pretty much need a step-by-step that is in laymen’s terms and not wiki jargon

I’m a total novice when it comes to all of this so thank you in advance
Natalie dit :
1 novembre 2006 à 04:11
Hi! I had just setup pre-patched archive and everything works BUT restricting log entries.

RecentChanges show both restriction log entries and restricted pages history even for not logged in users.

I copied LocalSettings.php part as is with no custom changes whatever.

The wiki is setup in Ukrainian if that matters.

What can be wrong? Any help would be much appreciated!
Jerome Combaz dit :
13 novembre 2006 à 16:11
@Stef : the group A that you mention is the ‘restrict’ group of the patch… 
 
Jerome
Stef dit :
13 novembre 2006 à 16:11
Hi to all
Is there a way to associate articles to a group A and then make them visible only to that group A and not to other groups?
Restrict option lock all the page with articles to the other grous and they are unable to open the mail page.
I would like that some user can open their owner mail page.
Thank you
Stefano
Holden dit :
10 décembre 2006 à 09:12
Is there a quick way to uninstall this patch, without re-installing mediawiki from scratch? Thanks
Jerome Combaz dit :
12 décembre 2006 à 10:12
Just replace modified files with original files. The genuine files should have a .orig extension. The database modifications will be ignored, and will be removed when you will change the protect statut of articles. 
 
Jerome
Sgrinwis dit :
26 janvier 2007 à 23:01
Hey,
Is it possible to have restricted pages searchable if a memeber of the ‘viewrestrict’ or ‘restrict’ group is the one doing the searching? It seems to me that this makes a lot of sense from a functionality point of view.

-Steve
Jerome Combaz dit :
29 janvier 2007 à 11:01
I think it’s the current behaviour. 
 
Jerome
kyle dit :
14 avril 2007 à 12:04
Hi Jerome,

Thanks for all your help with this patch. It really helped me get my site up and running. Now, however, I’m looking to open things up, so I won’t need a complicated restriction extension. It’s too bad that you’re switching wikis! Good luck with it.
D0li0 dit :
19 mai 2007 à 04:05
I have adjusted the MW 1.7.1 patch to (mostly) work with MediaWiki 1.10.0

It is not very well tested. So it is maybe not a good idea to use it in a productive environment without extensive testing.

See: meta.wikimedia.org/wiki/P…
D0li0 dit :
8 juin 2007 à 00:06
I’m having some trouble with the $wgRestrictNewPages option, It doesn’t seem to work with th update for MW1.10. I have verified that it does work with MW1.6.7 and the older 0.64 patch, although the new page appears in the recent changes unlike edits to restricted pages.

I’m not sure if I broke this in the 0.8.+ updates, or if it was broken by some previous change. perhaps the 0.70 change regarding "SQL requests are not modified anymore to check the restriction". I’m assuming that it was already broken in the 0.8 update.
Can anyone verify that $wgRestrictNewPages was still working with the use of patch versions 0.70, 0.71, 0.72, or 0.8? to help track down the problem?
Guido dit :
3 juillet 2007 à 02:07
Hi Jerome,

Thanks for all your help with this patch. It really helped me get my site up and running. It’s too bad that you’re switching wikis! I just want to say Thank you.
lodopidolo dit :
23 septembre 2008 à 11:09
There’s a extension that offer restricted access to your wiki, based on gropus and categories.
See: http://www.mediawiki.org/wiki/Extension:Restrict_access_by_category_and_group