Extension talk:Lockdown/LQT Archive 1

Clarification of permission precedence
I am using the Lockdown extension on my wiki with great success. I have not upgraded to 1.12 so I am still not running into problems. However, based on reading earlier posts, I was thinking a clairifcation on the inter-action between permissions granted in different places might be in order.

My wiki has to components: Public and Private. For each "private" area, I create a custom namespace and user group to access it. Each new user group can also use the public pages. So, currently I am granting permissions using $wgGroupPermissions and then granting another (often almost identical set) using Lockdown for the custom namespace. It seems that I may be doing a lot of extra permission granting, but I am not sure without a clarification on the interaction between permissions I grant to the new user group.

So, for example, I create a new user group using and grant the following permissions:

$wgGroupPermissions['newgroup']['read']= true; $wgGroupPermissions['newgroup']['edit']= true;

In the public area, I do not want them to be able to upload images. However, in the "private" area, I do want them to have that ability. So, if I enter this using the Lockdown extension for 'NS_NEWSPACE':

//Necessary code for require_once and declaring new namespace etc here....then this line: $wgNamespacePermissionLockdown[NS_NEWSPACE]['upload'] = array('newgroup');

Am I correct in reading below that this 'upload' only applies to the NEWSPACE using Lockdown?, Also, if in the code line above where I grant 'upload' I granted all permission using ['*'], would I be granting all permissions available or just the ones I granted using $wgGroupPermissions earlier (i.e. read and edit in this example)?

Thanks!! Qaaz

1.12 compatibility ?!
Seems that this extension doesn't work with 1.12 for restrict the read access Have you the same problem ? Regards

Same for me. Jon

There's a patch at the bottom of this page 86.141.194.36 19:36, 27 March 2008 (UTC)

It seems that the problem is only with public wiki. In case of non-public (I mean with options:

$wgGroupPermissions['*']['read'] = false; $wgWhitelistRead = array( "Special:Userlogin", "-", "MediaWiki:Monobook.css" );

) it works for me.

--zuo (85.222.69.4 00:26, 20 April 2008 (UTC))

Difference to NamespacePermissions Extension ?
The meta:NamespacePermissions_Extension seems to fulfill the same purpose. Can you elaborate on the differences?

Well, basically, I found a lot of different extensions for more fine grained access restrictions, decided I didn't quite like any of them, and so I went ahead and wrote my own :) The main differences to NamespacePermissions_Extension seem to be:


 * NamespacePermissions only applies to custom namespaces (ID >= 100), Lockdown to any namespace
 * Lockdown also provides a mechanism for controlling access to individual pages in the Special pseudo-namespace.
 * NamespacePermissions only supports read, edit, create, and move, while Lockdown supports all permissions, including delete for example.
 * NamespacePermissions uses special permission names like $wgGroupPermissions[ 'user' ][ 'ns100_edit' ] = true; to manage permissions for individual namespaces; Lockdown uses $wgNamespacePermissionLockdown[100]['edit'] = array('user'), which I find cleaner.
 * NamespacePermissions uses special magic groups as a shortcut to granting or denying acces to a specific namespace - to grant a user full access to namespace 102, you would add it to the group ns102RW; Lockdown uses permission wildcards instead - to restrict all access to namespace 102 to members of group xxx, you would set $wgNamespacePermissionLockdown['102']['*'] = array('xxx');, which I like better.

In the process of writing the Lockdown extension, I also plugged some holes regarding read-permissions (the holes are still open in 1.9.x). NamespacePermissions would benefit from that too, of course. -- Duesentrieb ⇌ 23:14, 23 February 2007 (UTC)

Changes to Work on MediaWiki 1.8.2
I got this extensions working fine on MediaWiki 1.8.2 with one slight change. In includes/Title.php, add this function to the Title class:

function isSpecial( $page ) {	return (($this->getNsText == "Special") && ($this->getText == $page)); }

-- Adrianm 6 March 2007

Basic Namespace Security Fix
This fix improves the security of many of the Special pages by enforcing the namespace restrictions provided by the Lockdown extension. Specific fixes are also required for many of the Special pages, which are addressed below this section. Tested in MediaWiki 1.8.2 by Adrianm.

This fix relys on the fact that many (but not all) Sepcial pages use the $wgContLang->getNamespaces function located in languages/Language.php to obtain their list of available namespaces. No namespace checking is performed by this function in the default MediaWiki install, and it doesn't call the hook used by the Lockdown extension. So, we add a step to the getNamespaces function which filters out restricted namespaces whenever the array is retrieved. Since a lot of MediaWiki classes use this function, a small change code in this function fixes bugs in a lot of places.

The solution involves two steps. Firstly, add the following two functions to Lockdown.php:

/* Checks whether the given namespace is visible to the user who is logged in. function namespaceIsVisible($ns) {	global $wgNamespacePermissionLockdown, $wgUser;
 * @author Adrian Mikula
 * @return Boolean

$groups = @$wgNamespacePermissionLockdown[$ns]['read']; if (!$groups) $groups = @$wgNamespacePermissionLockdown['*']['read']; if (!$groups) $groups = @$wgNamespacePermissionLockdown[$ns]['*']; if (!$groups) return true;

$ugroups = $wgUser->getEffectiveGroups; $match = array_intersect($ugroups, $groups); if ($match) return true; return false; }

/* Removes hidden namespaces from an array of namespaces. function filterHiddenNamespaces($namespaces) {	foreach ( $namespaces as $ns => $name ) {		if (!namespaceIsVisible($ns)) {			unset($namespaces[$ns]); }	}	return $namespaces; }
 * @author Adrian Mikula
 * @return array

And secondly, modify the following function in Language.php

function getNamespaces { $this->load; return $this->namespaceNames; }

To look like this:

function getNamespaces { $this->load; return filterHiddenNamespaces($this->namespaceNames); }

Now, special pages which have dropdown combos (eg. Special:Allpages) or checkboxes (eg. Special:Search) listing namespaces won't display namespaces which are restricted using $wgNamespacePermissionLockdown</tt>. Please note that many Special pages have additional security flaws that also need to be fixed. -- Adrianm 7 March 2007


 * Interesting! I was trying to accomplish the same thing and followed the same path. Then figured that there must be a way to do it without modifying Language.php. My approach was just like yours in creating a function to check permissions, only that I made mine generic:


 * Then, I added the following snippet to lockdownUserCan:


 * Just make sure you've declared the global variables $wgExtraNamespaces and $wgContLang in lockdownUserCan
 * Also note that this was made for the ExtraNamespaces. It's pretty simple to extend to all of them. --Kimon 16:37, 7 November 2007 (UTC)
 * Plus, this fixes the security exploit with Special:AllPages, Special:Export and Special:Search --Kimon 16:45, 7 November 2007 (UTC)

Default Namespace Fix
The purpose of this fix is to provide a secure way for Special pages to determine which namespace should be selected by default. Currently, most of the Special pages select the Main namespace by default, which is fine unless you wish to restrict access to the Main namespace. This fix assumes that the Basic Namespace Security Fix (above) has been performed.

Add the following to Lockdown.php</tt>.

/* Cycles through the namespaces in a specific order, and returns the function getDefaultNamespace {	$nsOrder = array(NS_MAIN, NS_CUSTOM_1, NS_CUSTOM_2, NS_HELP);
 * first namespace which the user has access to.

foreach ($nsOrder as $ns) {		if (namespaceIsVisible($ns)) return $ns; }	return -100; }

Change the namespaces to reflect the namespaces on your wiki, in order of preference. Then call this function whenever a Special page has to select a default namespace (ie. where you find $namespace = 0;</tt>). -- Adrianm 7 March 2007

fix for search results
To disable search results in namespaces the user can not read, the file specialsearch.php needs to be adjusted.

within function showMatches: while( $result = $matches->next ) { if ( ( $result->getTitle != NULL ) && ( $result->getTitle->userCanRead ) ) { $out .= $this->showHit( $result, $terms ); }		}

fix if Main namespace is restricted
It fixes a security flaw where searches are performed on the Main namespace by default if no namespace was supplied to the search page. This fix is only neccessary if you need to restrict access to the Main page. This fix assumes that the Basic Namespace Security and the Default Namespace fixes (above) have been performed.

We need to fix a line of code in includes/SearchMySQL.php</tt> which searches the Main namespace by default if no namespace was specified. Find the following function:

function queryNamespaces { $namespaces = implode( ',', $this->namespaces ); if ($namespaces == '') { $namespaces = '0'; }	return 'AND page_namespace IN (' . $namespaces . ')'; }

And change the line $namespaces = '0';</tt> to obtain a default namespace using getDefaultNamespace</tt>. Now, you should not be able to search the Main namespace if you don't check any other namespace boxes.

-- Adrianm 7 March 2007

Fix for Special:Allpages
This fixes a security flaw where pages from the the Main namespace are displayed on Special:Allpages when you first load the page. This fix is only neccessary if you need to restrict access to the Main page. This fix assumes that the Basic Namespace Security and the Default Namespace fixes (above) have been performed.

We need to fix a line of code in includes/SpecialAllpages.php</tt> which lists pages in the Main namespace by default if no namespace was specified. Find the following lines inside the function wfSpecialAllpages</tt>:

if (!in_array($namespace, array_keys($namespaces))) $namespace = 0;

And change the line $namespace = 0;</tt> to obtain a default namespace using getDefaultNamespace</tt>. Now, you should not be able to list pages from the Main namespace when you load Special:Allpages.

-- Adrianm 7 March 2007

Fix for Special:Recent changes
If you don't want recent changes from edits that you can't see to appear, use the following code (edited from Extension talk:NamespacePermissions)

In Specialrecentchanges.php:

Replace With Remeber to add To the top of the function (wfSpecialRecentchanges).

At least, it worked for me

--el_sjaako 84.104.220.211 14:24, 1 December 2007 (UTC)

Questions/Support
How does the new $wgNamespaceProtection fit into working with this extension?


 * $wgNamespaceProtection only handles edit permission, afaik. Don't use it if you use the Lockdown extension, that would be confusing... -- Duesentrieb ⇌ 23:57, 10 April 2007 (UTC)

Lockdown does not respect $wgWhitelistRead. I think it should.


 * Hm, I didn't test this, but Lockdown does nothing to bypass $wgWhitelistRead. It uses the generic UserCan hook - if that bypasses $wgWhitelistRead, that would be a bug I guss. Can you provide more details about what you are trying to do, and how? -- Duesentrieb ⇌ 23:55, 5 May 2007 (UTC)


 * In Title.php, in the function userCanRead, Mediawiki code looks at wgWhiteListRead only after wfRunHooks is called. I hope that explains why that happens. Let me now go on to what I am doing. In my setup (without using Lockdown), I blocked a namespace and allowed access to a single page in that namespace. I modified $wgWhitelistRead and userCanRead to do what I wanted. Now, I am using Lockdown, and blocked that namespace using $wgNamespacePermissionLockdown. Naturally, the page I wanted visible, is blocked as well. Thinking about it now, I don't know if it is Lockdown's job to support this. But, that is the issue.


 * Ah, now I understand. You want wgWhiteListRead to take preference over Lockdown - I thought you mean Lockdown undid the restrictions imposed by wgWhiteListRead. Hm, yea, sounds reasonable. I'll look into it. Maybe the whitelist check should go first... or maybe Lockdown should explicitely check wgWhiteListRead. -- Duesentrieb ⇌ 13:15, 6 May 2007 (UTC)


 * I just copied the code that checks for wgWhiteListRead from Title.php to the start of lockdownUserCan.

Fixed in 21946 -- Duesentrieb ⇌ 22:20, 6 May 2007 (UTC)


 * I think the code needs to set $result = true;
 * Not really - it returns true, which means "go on as usual". This in turn causes Title::userCan to look at wgWhiteListRead again and return true if appropriate. Setting $result to true would lead to the same result, I'm not completely sure which is the Right Thing to do: my way says "Lockdown does not apply to pages that are whitelisted", while setting $result to true would mean "Lockdown allows access to whitelisted pages". Since Lockdown is not designed to allow access, but to restrict it, returning true seems to be consistent. A quick test worked fine for me. -- Duesentrieb ⇌ 10:17, 7 May 2007 (UTC)
 * Sounds reasonable. You are right.

If I apply the Basic Namespace Security Fix on Language.php, the Namespace filtering affects also normal Links. A Link like MyNameSpace:Something is only displayed as :Something if I don't have the Right to read the Namespace. curry

I'm actually having trouble with this same issue. I would like to restrict access to the Main space (NS_MAIN), but I want the Main Page whitelisted. I have the following in my LocalSettings.php:
 * $wgWhitelistRead = array( ":Main Page", "Special:Userlogin", "-", "MediaWiki:Monobook.css" );

If I don't try to use $wgNamespacePermissionLockdown to restrict access to the main space, the above whitelist line allows anonymous users to read the Main Page, so it appears to be working fine then. However, when I implement a $wgNamespacePermissionLockdown on NS_MAIN, anonymous users and users outside the specifically allowed groups are unable to access the Main Page. I'm running the latest version of Lockdown, downloaded today. 198.178.147.1 23:18, 5 November 2007 (UTC)


 * And what version of MediaWiki? -- Duesentrieb ⇌ 12:29, 6 November 2007 (UTC)


 * Sorry, should've mentioned that. It's the latest MediaWiki+FCKeditor, which is based off of MediaWiki 1.10.1. 198.178.147.1 18:33, 6 November 2007 (UTC)


 * I could use $wgWhitelistRead</tt> overriding Lockdown as well, for Main Page (in the main namespace). I worked around it by setting MediaWiki:mainpage to a page in a namespace that is viewable, and Special:Movepage</tt>'ing the old main page to this new page. This covers users visiting the root of the site. I had to add an Apache redirect to get users visiting /Main_Page to /VisibleNamespace:Main_Page. Jlerner 03:11, 8 November 2007 (UTC)

Sequence of statements
As I understand it, the following sequence of settings is the correct way to set up Lockdown and NamespacePermissions, however, this is not working for me on MW ver 1.11. What is the correct sequence of settings to make this extension work, and why are they needed in that particular order? What is wrong with the below:

require_once( "extensions/Lockdown.php" );
 * 1) Step 1: enable extensions
 * 2) require_once( "extensions/NamespacePermissions.php" ); <-- you do not need this if you use lockdown!!

$wgSpecialPageLockdown['Export'] = array('sysop');
 * 1) Step 2: special lockdown

$wgExtraNamespaces[100] = "CodeReview"; $wgExtraNamespaces[101] = "CodeReview_talk";
 * 1) Step 3: Additional custom namespaces:

$wgGroupPermissions['GCodeReview']['read']   = true;
 * 1) Step 4: create group in Special:Userrights Special:Userrights:

$wgNamespacePermissionLockdown[100]['*'] = array('GCodeReview'); $wgNamespacePermissionLockdown[101]['*'] = array('GCodeReview');
 * 1) Step 5: Allow new group to access custom namespace

$wgNonincludableNamespaces[] = 100; $wgNonincludableNamespaces[] = 101;
 * 1) Step 6: prevent inclusion of pages from that namespace

Thanks! --Robert Fri, June 20, 2008, 2:23pm


 * Why would you want to install NamespacePermissions and Lockdown? They both do more or less the same thing, and may even conflict. -- Duesentrieb ⇌ 22:07, 20 June 2008 (UTC)


 * Right, that was the problem indeed. Removing the require_once statement for NSP fixed my problem. However, there is a resulting curious anomaly: in testing, when I attempt to access a restricted namespace with a user that does not have the correct proviledge, I get this: "The action you have requested is limited to users in one of the groups user, GCodeReview"  What I do not understand is why the group user would have access to this namespace since I did not grant any access to it. --Robert Tue, June 24, 2008, 11:25am
 * that message is misleading since it only takes into account the values in $wgGroupPermissions. I don't know if it would be possible to give a correct message there from an extension. Anyway, you can change the message to something generic by editing MediaWiki:badaccess-group1 on your wiki (or some other message -- if it doesn't work, check Special:Allmessages) -- Duesentrieb ⇌ 19:22, 24 June 2008 (UTC)

Image Lockdown --Makar 17:35, 20 August 2007 (UTC)
Is it possible to protect pictures or other uploaded files with lockdown in any way as well?


 * Makar, I wrote an extension to this extension also extending img_auth but it required extensive patching to run. Right now it only runs on 1.9.3 and 1.10.0.  but I'm using it extensively on several wikis.  The concept is this (where [ns] is your protected namespace ):
 * SpecialUpload into [ns]:[yourfile.jpg]
 * Reference as Image:[ns]:[yourfile.jpg] or Media:[ns]:[yourfile.jpg]


 * For example, given the protected namespace 'TEST', you would upload into TEST:Somefile.jpg and access as [[Image:TEST:Somefile.jpg]]


 * This enhancement was submitted as a bugfix, but given a wontfix status by the MediaWiki powers that be. The alternative is to use the new file classes, which I think are available in the new release 1.11.  If this is the case, I will spend the next couple of weeks trying to extend the classes instead of using this awkward syntax.  Wish me luck and I'll post here if successful.


 * If you want to try this out, go to NS Test Wiki and self-register. I'll grant access for testing to Testing Namespace-Based Protection.


 * If you need (or want) these patches, you can download them, but they are only available for MW 1.9.3 and 10.0.0:


 * Image NS Protection (Windows Zip)
 * Image NS Protection (TAR)
 * --jdpond 23:55, 5 September 2007 (UTC)


 * jdpond, thx for your respond. I will take a closer look on your work.--84.161.204.169 13:46, 9 September 2007 (UTC) (makar)


 * --Jlcaune 15:33, 21 October 2007 (UTC), I am very interested by the patch. Is it available for MW 1.11.0?

Include restricted Pages
This looks like a bug: I can include a page from a locked namespace, for example and the content is shown in the document where the INCLUDE tag is set. /Daniel --18:59, 9 December 2007 (UTC)

you have to use Manual:$wgNonincludableNamespaces to avoid that, the documentation explicitely mentions that, and all examples contain this. -- Duesentrieb ⇌ 20:15, 9 December 2007 (UTC)

Possible to restrict 'delete'
Hi I tried successfully to restrict the following rights on custom namespaces


 * read
 * edit
 * move
 * createpage

I did not succeed with 'delete'.

Is this not forseen in the extension or am I doing something wrong?
 * I havn't tried, and don't have much time for this right now.
 * gnerally, the extension implements logic for the userCan check. If the deletion mechanism doesn't use userCan to dertermine if the user can delete, i would consider that a bug in the core code. Which I should then probably fix :)
 * I'll look into this soonish. Please remind me if I should forget. -- Duesentrieb ⇌ 08:57, 7 September 2007 (UTC)


 * Update: I have looked into the code, and it seems that Lockdown will not work for the delete permission (or protect, or patrol, etc). The reason is this: there are per-page permissions (checked using userCan), and global permissions (checked using isAllowed). Lockdown hooks into userCan, and thus only covers per-page permissions. However, several permissions that do conceptually apply to pages (like delete) are still treated as global permissions by mediawiki, and are thus not accessible to the Lockdown extension. I might change this in the MediaWiki core, but not before 1.12. -- Duesentrieb ⇌ 08:44, 10 September 2007 (UTC)

Allowing restriction to all but a few special pages
By Viybel 13:16, 18 September 2007 (UTC)

At present, if you want to restrict all but a few special pages, you need to specify a long list of $wgSpecialPageLockdown, because $wgNamespacePermissionLockdown[NS_SPECIAL] is skipped by the script.

To make it work, you just need to modifify a few lines in Lockdown.php:

Replace : else { $groups = @$wgNamespacePermissionLockdown[$ns][$action]; if (!$groups) $groups = @$wgNamespacePermissionLockdown['*'][$action]; if (!$groups) $groups = @$wgNamespacePermissionLockdown[$ns]['*']; }

by

if (!$groups) $groups = @$wgNamespacePermissionLockdown[$ns][$action]; if (!$groups) $groups = @$wgNamespacePermissionLockdown['*'][$action]; if (!$groups) $groups = @$wgNamespacePermissionLockdown[$ns]['*'];

So now you can use:

$wgSpecialPageLockdown['Search'] = array('*'); $wgSpecialPageLockdown['Userlogin'] = array('*'); $wgSpecialPageLockdown['Userlogout'] = array('*'); $wgNamespacePermissionLockdown[NS_SPECIAL]['read'] = array('sysop');

or even quicker:

$wgWhitelistRead = array("Special:Userlogin","Special:Userlogout", "Special:Search"); $wgNamespacePermissionLockdown[NS_SPECIAL]['read'] = array('sysop');

It would be nice if Duesentrieb could include this in the next release. Viybel 13:16, 18 September 2007 (UTC)


 * This feature is great ! Please add this feature directly in the code !


 * + 1, very handy, once I understoud this point : $wgWhitelistRead needs the wiki language, e.g. with the above example in french :

$wgWhitelistRead = array("Special:Connexion","Special:Déconnexion", "Special:Recherche"); $wgNamespacePermissionLockdown[NS_SPECIAL]['read'] = array('sysop');
 * --NewMorning 10:38, 29 June 2008 (UTC)

Bug or configuration problem
At first, thanks a lot for your nice work. I tried to use this extension in MW 1.11.0 and I doesn't work...

Here is the code entered in Localsettings.php (Lockdown is in the right place, without subdirectory)

$wgExtraNamespaces = array(100 => "Motion",                          101 => "Motion_talk",                           102 => "BN",                           103 => "BN_talk"                           );

require_once( "$IP/extensions/Lockdown.php" );
 * 1) Lockdown

$wgSpecialPageLockdown['Export'] = array('user');

$wgNamespacePermissionLockdown[102]['edit'] = array('BN'); $wgNamespacePermissionLockdown[102]['view'] = array('BN');

$wgNonincludableNamespaces[] = 102;

But then, when I go on : http://wikips.olympe-network.com/mediawiki/index.php?title=BN:BN_Doc1

Even as anonymous, it is possible to view the page... Did I miss something ? made something wrong ? or does it come from 1.11.0 ?

Best regards, Rmatt

i would be also interesseted in the answer or any idea...have the same problem but the difference is that i'm using 1.10 Moonlight 10:33, 12 October 2007 (UTC)

Sorry, I have no idea what the problem could be. Generally, of you don't want people the read a page though, you don't want them to be able to do anything with that page. so it would make more sense to set $wgNamespacePermissionLockdown[102]['*'] = array('BN'); But setting the restriction for view alone should also work. -- Duesentrieb ⇌ 11:48, 12 October 2007 (UTC)

User group access
Shouldn't I be able to have rights to a page if I'm a user who belongs to the group who has rights?

My LocalSettings.php file contains:

$wgExtraNamespaces = array(110 => "dlib", 111 => "dlib_Talk");

require_once('extensions/Lockdown.php'); $wgSpecialPageLockdown['Export'] = array('user'); $wgNamespacePermissionLockdown[110]['*'] = array('dlib');
 * 1) Lockdown

I am part of the dlib usergroup, but still cannot access the page.


 * Depends on what you have set in $wgGroupPermissions. Lockdown can only restrict access, not grant it if it was forbidden before.
 * Basically, $wgNamespacePermissionLockdown[110]['*'] sais "no one that is not in dlib has any access to namespace 110". It does NOT say "everyone in dlib has access to namespace 110".
 * -- Duesentrieb ⇌ 09:01, 3 March 2008 (UTC)

Permissions bug
I'm currently using MediaWiki 1.11.1, and I'm attempting to make it so only users in a certain group can do anything with two specific namespaces. I've already tried to see if I was doing anything wrong on a thread on mwusers.com, and it ended with the person who was helping me saying that it may be a bug, so here I am. This is the code I'm using:

define("NS_ENORIS_RPG", 100); define("NS_ENORIS_RPG_TALK", 101); $wgExtraNamespaces[NS_ENORIS_RPG] = "Enoris_RPG"; $wgExtraNamespaces[NS_ENORIS_RPG_TALK] = "Enoris_RPG_Talk"; $wgNonincludableNamespaces[] = array(NS_ENORIS_RPG, NS_ENORIS_RPG_TALK); $wgNamespacePermissionLockdown[NS_ENORIS_RPG]['*'] = array('speceditor'); $wgNamespacePermissionLockdown[NS_ENORIS_RPG_TALK]['*'] = array('speceditor'); $wgGroupPermissions['*']['speceditor'] = false; /* Just a safety precaution */ $wgGroupPermissions['Special Editor']['speceditor'] = true;

I had another version where the contents of  was the   usergroup, as I wasn't entirely sure how to use this extension, and I was told to change it. If it's not a bug, I'm sorry for wasting your time. 72.72.240.151 03:37, 3 March 2008 (UTC)


 * I'm not sure why it wouldn't work at all, but for one thing, you are confusing groups and permissions (read Help:User_rights and Manual:User rights management). In $wgNamespacePermissionLockdown[NS_ENORIS_RPG]['*'] = array('speceditor') you are using "speceditor" as a user group, which I suppose is correct (Skizzer's statement that "NamespacePermissionLockdown tests permissions, not group membership" is a bit misleading - it tests for group membership, and overrides permisions based on that and the current namespace). In  $wgGroupPermissions['Special Editor']['speceditor'] = true you are treating it as a permission, and assign it to a group called "Special Editor", which doesn't make sense to me.
 * Actually, you shouldn't have to do much with $wgGroupPermissions, except use the group somewhere, so mediawiki kinows it exists (yes, a group exists if it is used in $wgGroupPermissions, simple as that). I would use something redundant like $wgGroupPermissions['speceditor']['read'] = true;
 * But anyway, your config should have worked in so far as to not allow anyone not in the "speceditor" group to read or edit pages in the Enoris_RPG or Enoris_RPG_Talk namespaces. The only problem I can think of off-hand is: where's the require_once statement? the config must come after including the extension using require_once.
 * You can often find me on IRC to get direct help: irc://irc.freenode.net/mediawiki
 * -- Duesentrieb ⇌ 08:56, 3 March 2008 (UTC)


 * Oh god, I'm a moron. I did have it included before the user rights, until I moved the user rights to another file and moved stuff around a bit. It's working now.
 * Also, I did have it like how it was before, but Skizzers' told me (Rr at least I thought he did. Probably misinterpretation.) that I had to set this up with $wgNamespacePermissionLockdown was a permission, though I didn't think it did. Regardless, thank you for your help, and sorry for wasting your time with a rather mundane problem. =P 72.72.240.151 01:44, 4 March 2008 (UTC)
 * My bad >_> --Skizzerz talk - contribs [[Image:Tournesol.png|20px]] MediaWiki Support Team  02:05, 4 March 2008 (UTC)

Multiple Namespaces
I'm trying to setup multiple namespaces with differing permissions - i.e. a IS namespace that ISusers have full permissions to, and a HR namespace that only HRusers have full permissions to.

For testing purposes I created three users - IStest (member of ISuser group), HRtest (member of HRuser group), and generic (normal user). For some reason, despite identical user permissions in the DefaultSettings.php and configurations in LocalSettings.php, I'm experiencing dissimilar results. The IS namespace is properly protected, but the HR namespace appears to be unaffected. Below is my code for the namespace configurations:


 * 1) -Access Control via Lockdown Extension--##
 * 1) -Access Control via Lockdown Extension--##

require_once( "$IP/extensions/Lockdown/Lockdown.php" );
 * 1) Require the extension. If this gets screwy, comment out the following line

$wgSpecialPageLockdown['Export'] = array('sysop');
 * 1) Special page lockdown - prevents exporting entire wiki to get protected content

define('NS_IS', 100); define('NS_IS_TALK', 101);
 * 1) Define custom namespaces
 * 2) IS Namespace

define('NS_HR', 110); define('NS_HR_TALK', 111);
 * 1) HR Namespace

$wgExtraNamespaces[NS_IS] = 'IS'; $wgExtraNamespaces[NS_IS_TALK] = 'IS_talk'; $wgExtraNamespaces[NS_HR] = 'HR'; $wgExtraNamespaces[NS_HR_TALK] = 'HR_talk';
 * 1) --Namespace Configuration---##
 * 2) Create namespaces

$wgNamespacePermissionLockdown[NS_IS]['*'] = array('ISuser'); $wgNamespacePermissionLockdown[NS_IS_TALK]['*'] = array('ISuser'); $wgNamespacePermHRsionLockdown[NS_HR]['*'] = array('HRuser'); $wgNamespacePermHRsionLockdown[NS_HR_TALK]['*'] = array('HRuser');
 * 1) Restrict permissions to correct group

$wgNonincludableNamespaces[] = NS_IS; $wgNonincludableNamespaces[] = NS_IS_TALK; $wgNonincludableNamespaces[] = NS_HR; $wgNonincludableNamespaces[] = NS_HR_TALK;
 * 1) Prevent inclusion of pages from that namespace

Also, what's the standard (if any) for numbering custom namespaces? I went with 100/101, 110/111, 120/121, etc. Is any number above 100 fair game? --Pezhore 17:20, 18 March 2008 (UTC)


 * Just for the record: The reason should be the wrong syntax in $wgNamespacePermHRsionLockdown.... You have replaced too much. :) --Nk 08:19, 24 June 2008 (UTC)

Patch to work in 1.12
In 1.12 a security regression was made, the following patch fixes that -- this should be used for now, or if the fix isn't backported to 1.12.

Index: includes/Title.php

=
====================================================== --- includes/Title.php  (revision 32324) +++ includes/Title.php  (working copy) @@ -1383,10 +1383,6 @@       public function userCanRead { global $wgUser, $wgGroupPermissions;

-              # Shortcut for public wikis, allows skipping quite a bit of code path -              if ($wgGroupPermissions['*']['read']) -                      return true; -               $result = null; wfRunHooks( 'userCan', array( &$this, &$wgUser, 'read', &$result ) ); if ( $result !== null ) {

MinuteElectron 09:30, 22 March 2008 (UTC)


 * Thanks MinuteElectron for this tweak ! It is also possible to simply comment the lines 1387 ans 1388. Anyway, it is not perfect, since the protected page now have "Title Error" as title and indicates that we must be connected to see the other pages. It could be understood as an site error by not connected people. --Rmatt 13:43, 22 March 2008 (UTC)
 * i can confirm this patch to be functional an I don't get that "Title Error" on my wiki. --Jamasi 21:31, 15 May 2008 (UTC)
 * are the mediawiki dev informed on this issue ? 21:21, 22 March 2008 (UTC)


 * Yes, and if and how it is going to be resolved is unclear. See this thread. Either the logic is changed in MedisWiki again (not before 1.12.1) or I have to change how Lockdown works (effectively making it "Lockup"). -- Duesentrieb ⇌ 20:11, 24 March 2008 (UTC)


 * http://lists.wikimedia.org/pipermail/wikitech-l/2008-March/037124.html
 * Is this patch correct for you ? okparanoid 83.145.100.34 09:10, 25 March 2008 (UTC)


 * Did anyone tested it woth 1.13? 134.147.154.66 10:09, 23 April 2008 (UTC)

This change might mean that the problem is fixed in 1.13. I havn't it checked yet though. -- Duesentrieb ⇌ 20:57, 4 June 2008 (UTC)

Is the patch still needed ?
I just checked my version of MediaWiki 1.12 and it happens that my titles.php is exactly the same as the patch code : is that flaw fixed in SVN ?--NewMorning 05:53, 22 June 2008 (UTC)
 * YOu mean there's no "if ($wgGroupPermissions['*']['read'])..." in your version? Sure? -- Duesentrieb ⇌ 08:43, 22 June 2008 (UTC)

Nope : I mean that I could not figure out why there was "-" before those lines : I guess I have to comment them ( # rather than - ) so many thanks to you --NewMorning 09:02, 22 June 2008 (UTC)
 * Generally, you don't do that yourself, you use the "patch" program to do that :) -- Duesentrieb ⇌ 19:07, 22 June 2008 (UTC)

How to block Users pages from public ?
Simple in fact... : $wgNamespacePermissionLockdown[NS_USER]['read'] = array('user'); ... But how can I restrict Talk pages ? --NewMorning 23:56, 24 June 2008 (UTC)


 * The same way: for example, $wgNamespacePermissionLockdown[NS_USER_TALK]['read'] = array('user');</tt> -- Duesentrieb ⇌ 07:36, 25 June 2008 (UTC)

This gave me :"Parse error: syntax error, unexpected T_VARIABLE in .../wiki/LocalSettings.php on line 254
 * Then you forgot the ";" before or after this line. -- Duesentrieb ⇌ 21:41, 25 June 2008 (UTC)

Possible: I don't get the parse error anymore. But this did not prevent access either.--NewMorning 17:33, 26 June 2008 (UTC)

Trouble to lock Talk pages
I both tried with this extension and with $wgGroupPermissions['*']['read'] = false; : the Talk page remains readable for non-connected users on my 1.12 Wiki : where can this come from ?--NewMorning 18:08, 26 June 2008 (UTC)
 * As stated at the top of teh description page, Lockdown does not work with 1.12. Not sure if $wgGroupPermissions['*']['read'] = false would work, there was a "shortcut" introduced that cut out most access checks for reading. The problem will be fixed in 1.13, at least wrt Lockdown. Or you can use the patch mentioned above. -- Duesentrieb ⇌ 19:27, 26 June 2008 (UTC)

I precisely did : this does not seem sufficient for Talk pages, and I wonder if making Talk pages inaccessible is possible at all in 1.12, independently of this extension. I might start trying 1.13 --NewMorning 04:36, 27 June 2008 (UTC)
 * I can't see why talk pages should at all be different from other pages. Make sour you got the right constant for the talk namespace you are trying to protect. -- Duesentrieb ⇌ 11:48, 27 June 2008 (UTC)

I don't know what was wrong at first attempts but it now works fine : many thanks. --NewMorning 10:29, 29 June 2008 (UTC)