Extension talk:Lockdown/Archive 1

Problems with 1.16.x (Summary)

Several people have posted persistent problems using this extension with 1.16.x, where it overrules permissions set with $wgGroupPermissions. Several people have mentioned this happens even without using any lines other than enabling the extension itself, so this does not appear to be user (or RTFM) error IMO.

134.161.225.55 gave specific steps for reproducing the bug by deleting the session on an affected Mediawiki server (see below).

However, other people have been able to use it without any issue. This makes me wonder if there's another variable here.

Could people fill out what OS/Apache/php versions they're running with and without problems?

Works in 1.16.x

Not Working in 1.16.x

Otherwise, if anyone has ideas for people to try (so we could rule out or prove user error), please post below. So far none of the people it wasn't working for before have been able to come back and say, "Oops, yes, I found my mistake". It seems unlikely that this many people are having issues and taking the time to post (saying they've only enabled the extension in order for it to break things) if it's just user error, but we should find out for sure.

Double-Check These

ActionLockdown does not display a message

Unlike Namespace and SpecialPage lockdowns, actionlockdown do not display an error message. Instead, I get an empty page. Example: https://www.hackerspace.lu/w/index.php?title=Toolset_Workshop&action=formedit Here the formedit action is only allowed to 'user'. Where would such a redirecting message have to be added? --Clausekwis 11:10, 24 November 2010 (UTC)

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

Questions

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 meta: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

Fixes for Security Flaws

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.
*  @author Adrian Mikula
*  @return Boolean
*/
function namespaceIsVisible($ns)
{
	global $wgNamespacePermissionLockdown, $wgUser;

	$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.
*  @author Adrian Mikula
*  @return array
*/
function filterHiddenNamespaces($namespaces) 
{
	foreach ( $namespaces as $ns => $name ) 
	{
		if (!namespaceIsVisible($ns))
		{
			unset($namespaces[$ns]);
		}
	}
	return $namespaces;
}

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. 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:

function lockdownCanAction($ns, $action, $user) {
        global $wgNamespacePermissionLockdown, $wgSpecialPageLockdown, $wgWhitelistRead, $wgTitle;

        $groups = NULL;
        if( NS_SPECIAL == $ns ) {
                if ($action != 'read') {
                        return true;
                }
                else {
                        foreach ($wgSpecialPageLockdown as $page => $g) {
                                if (!$wgTitle->isSpecial($page)) continue;
                                $groups = $g;
                                break;
                        }
                }
        }
        else {
                $groups = @$wgNamespacePermissionLockdown[$ns][$action];
                if (!$groups) $groups = @$wgNamespacePermissionLockdown['*'][$action];
                if (!$groups) $groups = @$wgNamespacePermissionLockdown[$ns]['*'];
        }

        if (!$groups) return true;

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

Then, I added the following snippet to lockdownUserCan():

$newNS = array();
foreach($wgExtraNamespaces as $klns => $lns) {
        if(lockdownCanAction($klns, 'read', $user)) {
                $newNS += array($klns => $lns);
        }
}
$wgExtraNamespaces = $newNS;
$wgContLang->mLoaded = false;
$wgContLang->load();

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.

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

	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;). -- Adrianm 7 March 2007

Fix for Special:Search

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 );
			}
		}

This fix will only work if you have not allowed read access to all of NS_MAIN. The userCanRead function returns true if it finds $wgGroupPermissions['*']['read'] and ignores further searches for lockdowns.

To do the full search for all permissions, you need to use the $doExpensiveQueries = true, which should be done as:

		while( $result = $matches->next() ) {
			if ( ( $result->getTitle() != NULL ) && (
			$result->getTitle()->userCan('read') ) ) {
				$out .= $this->showHit( $result, $terms );
			}
		}

--jdpond 11:41, 20 August 2009 (UTC)

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 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'; to obtain a default namespace using getDefaultNamespace(). 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 which lists pages in the Main namespace by default if no namespace was specified. Find the following lines inside the function wfSpecialAllpages():

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

And change the line $namespace = 0; to obtain a default namespace using getDefaultNamespace(). 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

	# Namespace filtering
	$hidem .= is_null( $namespace ) ?  '' : ' AND rc_namespace' . ($invert ? '!=' : '=') . $namespace;

With

    # Namespace filtering
	$hidem .= is_null( $namespace ) ?  '' : ' AND rc_namespace' . ($invert ? '!=' : '=') . $namespace;

	foreach ( $wgExtraNamespaces as $num => $title ) {
            if (!namespaceIsVisible($num)) {
                $hidem .= ' AND rc_namespace!='.$num;
            }
        }

Remeber to add

	global $wgExtraNamespaces;

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 rev: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 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'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:

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

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

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

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

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

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

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)

Feature Requests

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):

1. SpecialUpload into [ns]:[yourfile.jpg]
2. 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?

--jdpond 11:47, 20 August 2009 (UTC), For versions >1.13, you can now use Extension:NSFileRepo which implements as seen above.

Bugs

Include restricted Pages

This looks like a bug: I can include a page from a locked namespace, for example

 {{LOCKED_NS:Page}} 

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

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

$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");

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

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 array() was the Special Editor 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} 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:

##----------------------------------------------------------------------------##
##-----------------Access Control via Lockdown Extension----------------------##
##----------------------------------------------------------------------------##

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

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

## Define custom namespaces
# IS Namespace
define('NS_IS', 100);
define('NS_IS_TALK', 101);

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

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

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

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

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 ) {

The above "Patch" does this mean that you should comment out the lines maked with - or something else? Why not then just show the code to be? --Asset 17:01, 25 November 2008 (UTC)

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)

mailarchive: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'); -- 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)

Dont work for me

1.12 - Tried to do this, and I did comment out the lines in Title.php (dont understand why you use - to mark the lines to comment out though?)

For some reasons this don't work AT ALL - any user can go to Special:Filelist, and read the MO: pages??

##----------------------------------------------------------------------------##
##-----------------Access Control via Lockdown Extension----------------------##
##----------------------------------------------------------------------------##

# Lockdown start 
require_once( "$IP/extensions/Lockdown.php" );
 
# Lockdown fine
$wgSpecialPageLockdown['Filsti'] = array('user');
$wgSpecialPageLockdown['Filsti'] = array('laerer');

# Name Spaces 100, 101 
define('NS_MO', 100);
#define("NS_MO_TALK", 101);
 
$wgExtraNamespaces[NS_MO] = "MO";
#$wgExtraNamespaces[NS_MO_TALK] = "MO_talk";
 
$wgNamespaceProtection[NS_MO] = array( 'editmo' ); 
#$wgNamespacesWithSubpages[NS_MO] = true;          

# NS permisions

$wgGroupPermissions['*']['editmo'] = false;      
$wgGroupPermissions['user']['editmo'] = false;   
$wgGroupPermissions['laerer']['editmo'] = false; 

$wgSpecialPageLockdown['Filsti'] = array('*','user','laerer');

#Lockdown restrict "read" permission to logged in users

#$wgNamespacePermissionLockdown[NS_OM]['edit'] = array('*', 'user', 'laerer', 'lærer' );
$wgNamespacePermissionLockdown[NS_OM]['read'] = array('*','user','laerer' );

#prevent inclusion of pages from that namespace
$wgNonincludableNamespaces[] = 100;
$wgNonincludableNamespaces[] = 101;

Several things:

• you defined NS_MO, and then used NS_OM $wgNamespacePermissionLockdown -- that can't work.
• don't mix $wgNamespacePermissionLockdown and $wgNamespaceProtection, that is bound to get confusing
• What is Special:Filelist? I have never seen that. If some extension does not check the Title::userCan before shopwing stuff, there's nothing I can do about that.
• Lockdown does not prevent pages from being listed, it only prevents the content from being shown.

HTH -- Duesentrieb ⇌ 06:31, 14 July 2008 (UTC)

Thanx

• Dam! I knew it was late last night, but not that late!
• I know i should not mix, but I was desperate!
• should be Special:FilePath - but the danish Translattion was Special:Filsti - and that I then translated "back" to Filelist! -- Asset

Special:FilePath is for image/media files. Lockdown does not protect uploaded files, only wiki pages. Usually, files are served directly by the webserver, without mediawiki ever getting called. There's some information about that at Extension:Lockdown#Additional_measures. -- Duesentrieb ⇌ 11:39, 14 July 2008 (UTC)

Oh, and i *think* you have to use canonical names in $wgSpecialPageLockdown, i.e. in this case FilePath. But that would only protect the special page, making images harder to find. This does not really protect the image files (see above). -- Duesentrieb ⇌ 11:41, 14 July 2008 (UTC)

Thanks a bunch! I did actually not intent to block the FilePath, I simply used this to debug if "any lockdown function was working". (Remark: In the Danish version I don't se the Special:Version function visibel on the special pages, så I actually could not verify that the extension was active... i geuss that such special functions can be hidden in some version, for some reason).

One general objection aginst Wiki is that I find it near impossibel to search for help, say I want to use special chars in the PHP code - 'lærer' as a user group - but when it is seen I get som strange char.

Also I have installed Wiki on a server with no email support, but I can not figure how to change the settings for email submit etc. (autentication) - either this is not an problem for anyone else(!!!) or do I need special care and instructions.

Dont worry - I love your work!

In short

• If you want non-ascii characters, set your text editor to UTF-8, with no BOM.
• If you do not have a local MTA for sending mail, use $wgSMTP
• If you need help, ask at the Support desk

Keep in mind that in comparison to other FOSS projects, MediaWiki is relatively well documented. Relatively :) -- Duesentrieb ⇌ 12:35, 14 July 2008 (UTC)

• Great, I have seen (and done) much worse. My requestions are not critical, but I suggested that each question raised, points to a potential improvement of the documentation.
• Say $wgSMTP contains a warning, but I have no idea if this waring is still valid - or simply something valid at some point in the past. Searching for help reagardin mail setup did not lead me to this, to an outsider SMTP is a word that you see only once in a lifetime, when you set up outlook.)

XSS problem and solutions

I would love your comments on how to solve a security problem, I have outlined it here: Global_session_threat_assessment#Using_external_anonymous_services. << Corrected

I use Lockdown to let people work with "non-public" texts that I need to be translated. But the Google gadget needs anonymous access, so my suggestion is to have an open page that will be removed on the fly - and it can only be created by a user that has the access via logged on. Anyway I will probably need to use code similar to, or building on, Lockdown to make such a thing work? --Asset 11:43, 28 July 2008 (UTC)

Special page lockdown is extremely case sensitive

After setting up lockdown on a number of special pages I spent 3-4 hours trying to work out why some worked and others didn't. For example:

$wgSpecialPageLockdown['FileDuplicateSearch'] = array('sysop');  // worked fine

$wgSpecialPageLockdown['MostLinkedTemplates'] = array('sysop'); // did NOT work

I finally discovered that the upper and lower case in the labels is critical. I had been copying the URL after "Special:" from the list in Special:SpecialPages. This doesn't always work. What does seem to work is to respect exactly the same combination of capitals and lower case as the file names in includes/specials.

The MostLinkedTemplates script is called SpecialMostlinkedtemplates.php and NOT SpecialMostLinkedTemplates.php

Respecting the same case fixed the problem:

$wgSpecialPageLockdown['Mostlinkedtemplates'] = array('sysop'); // DOES work

Help is appreciated

I am sorry if this is not the proper place to post this, but I can't seem to get the Lockdown extension to behave properly. Here is what I have done, please tell me if there is anything not correct. I am using MW 1.13.3

Snips from LocalSettings.php:

//Add Lockdown Extension
require_once( 'extensions/Lockdown/Lockdown.php' );

//add Custom Namespaces
define("NS_KB", 100);
define("NS_KB_TALK", 101);
$wgExtraNamespaces[100] = "KB";
$wgExtraNamespaces[101] = "KB_TALK";
$wgContentNamespaces[] = 100;

//Define a group called support and give read access and write access
$wgGroupPermissions['Support']['read']            = true;
$wgGroupPermissions['Support']['edit']            = true;

//Restrict all permissions to sysop, Manager and Support groups (
$wgNamespacePermissionLockdown[NS_KB]		['*'] 		= array('sysop, Manager, Support');

What I expect, is that if I log in with a Support user (or sysop or Manager) then I should be able to read or edit articles in the KB namespace. However, I get the message regardless of who I sign in with:

Permission error
The action you have requested is limited to users in one of the groups *, Users, Sysops, ACE, Support, Manager.

Return to Main Page.

The tabs in the config are to line up the values for my lists, please let me know if this affects the outcome, but I did try deleting them.

Is there anything that I'm Missing? BTW - Special Page Lockdown works excellently, thank you for such a useful extension.
Thanks, --Tcronin 22:16, 22 January 2009 (UTC)

Your setup looks OK, except the ExtraNamespaces bit is a bit curious. I'd recommend this (provided "KB" is the human redable name you want to use):

$wgExtraNamespaces[NS_KB] = "KB";
$wgExtraNamespaces[NS_KB_TALK] = "KB_talk";
$wgContentNamespaces[] = NS_KB;

I.e. use the constants you defined, and use lower case "talk" to be consistent with other talk namespaces.

As to the permission error, I can only imagine that you have restricted editing globally - if you have something like $wgGroupPermissions['*']['read'] = false; somewhere, then no one will be able to edit anything, no matter what you do with

$wgNamespacePermissionLockdown. Lockdown restricts rights, it does not override existing restrictions.

Other than that, I can only suggest to look at Special:Listusers and confirm that the users are actually in the groups you think they are in. And... group names are usually lower case. Using capitalized names should not cause problems, but you never know.

Oh, one more thing: make sure the ids 100 and 101 are not used again somewhere else.

HTH -- Duesentrieb ⇌ 08:13, 23 January 2009 (UTC)

Thank you Duesentrieb, I added the suggestions that you made to my config, but that did not solve it. It turns out that I am just a big bucket of bonehead on this one. I noticed that if I only put one group in the array it worked, but when I added another group it failed. Well here's what I did>

$wgNamespacePermissionLockdown[NS_KB]		['*'] 		= array('sysop, Manager, Support');
//changed this to the following (after making the groups all lower case)
$wgNamespacePermissionLockdown[NS_KB]		['*'] 		= array('sysop', 'manager', 'support');

and it works. I am sorry if this took more than a second of your time, it wouldn't have been worth it.

More rights then i should have.

I tried to build a custom namespace, which can only one group edit but everyone read. My Definiton looks like this

 define( "NS_SE_PUB", 172 );
 
 $wgExtraNamespaces[NS_SE_PUB] = "SE-Public";
 $wgContentNamespaces[] = NS_SE_PUB;
 
 $wgNamespacePermissionLockdown[NS_SE_PUB]['*'] = array('sa');
 $wgNamespacePermissionLockdown[NS_SE_PUB]['read'] = array('user');
 
 $wgNonincludableNamespaces[] = NS_SE_PUB;

So its like all the example. I'm member of the group sysop, user, * and se (which has the same rights as sysop) ans i also tested it with an user who is only member of user and *. With both users i got full access to the page instead of only read.

Is this a bug with 1.13 or did i just miss something?

--Lqd 15:42, 11 February 2009 (UTC)

What about Mediawiki 1.14?

Works in 1.14? 79.148.51.16 21:15, 28 February 2009 (UTC)

ActionLockdown not working in MW 1.14?

Hey there. I'm using MW 1.14 with the 1.14 version of the plugin and the SpecialPageLockdown functionality works great, but I can't seem to get ActionLockdown to work. Here's a snip from LocalSettings.php:

#LockDown
$wgSpecialPageLockdown['Listusers'] = array('sysop');
$wgSpecialPageLockdown['Export'] = array('sysop');
$wgSpecialPageLockdown['Version'] = array('sysop');
$wgActionLockdown['history'] = array('sysop');
$wgActionLockdown['watch'] = array('sysop');

All three of the SpecialPage lines work, but I'm still able to access history and watch as a standard user. Any help is greatly appreciated.

Dan D. | 3/11/2009 3:33 PM CST

I gave this some more thought, and obviously the lines above won't do what I wanted them to do. So, I tried:

$wgActionLockdown['history'] = array('*','user');

and still no dice. Any help rendered is appreciated!

Dan D. | 3/18/2009 4:24 PM CST

Lockdown working "to good"

---

Hi there, I have a little problem with the extension. Basically, I would like to have an access controll to allow members of a special group to see pages from a certain namespace only (e.g. group "limited" is allowed to see only pages in group "limited" and so on). The snip of the code is attached. I have two groups each - one for the "normal" page, one for the "_talk". My problem is that the access controll via the special page is not working correctly: A user is selected for "calendar" and "calendar_talk" but can not access the page. Q1) I the coding and its order correct? Q2) Is there a certain order on which user logins, setting up a certain page and / or giving or denying access need to take place?

In other words: The activation of access via the access controll (special page) does not work

Thanks a lot!! Christian

 # Require Extension #
 require_once( "extensions/Lockdown/Lockdown.php" );
 # Special Page Lockdown #
 $wgSpecialPageLockdown['Export'] = array('sysop');
 $wgActionLockdown['history'] = array('sysop');
 # Namespace #
 define ('NS_PRIVAT', 100);
 define ('NS_PRIVAT_TALK', 101);
 define ('NS_CALENDAR', 102);
 define ('NS_CALENDAR_TALK', 103);
 define ('NS_LIMITED', 104);
 define ('NS_LIMITED_TALK', 105);
 # Namespace Configuration #
 $wgExtraNamespaces[NS_PRIVAT] = 'Privat';
 $wgExtraNamespaces[NS_PRIVAT_TALK] = 'Privat_talk';
 $wgExtraNamespaces[NS_CALENDAR] = 'Calendar';
 $wgExtraNamespaces[NS_CALENDAR_TALK] = 'Calendar_talk';
 $wgExtraNamespaces[NS_LIMITED] = 'Limited';
 $wgExtraNamespaces[NS_LIMITED_TALK] = 'Limited_talk';
 #Namespace with Subpages #
// Puts the events into Subpages 
 $wgNamespacesWithSubpages[100] = true;
 $wgNamespacesWithSubpages[101] = true;
 $wgNamespacesWithSubpages[102] = true;
 $wgNamespacesWithSubpages[103] = true;
 $wgNamespacesWithSubpages[104] = true;
 $wgNamespacesWithSubpages[105] = true;
 # Customized Groups
 $wgGroupPermissions['privat']['edit'] = true;
 $wgGroupPermissions['privat_talk']['edit'] = true;
 $wgGroupPermissions['limited']['edit'] = true;
 $wgGroupPermissions['limited_talk']['edit'] = true;
 $wgGroupPermissions['calendar']['edit'] = true;
 $wgGroupPermissions['calendar_talk']['edit'] = true;
 # Lockdown - Restrict access to namespaces for group memebers
 $wgNamespacePermissionLockdown[NS_PRIVAT]['*'] = array ('Privat');
 $wgNamespacePermissionLockdown[NS_PRIVAT_TALK]['*'] = array ('Privat_talk');
 $wgNamespacePermissionLockdown[NS_CALENDAR]['*'] = array ('Calendar');
 $wgNamespacePermissionLockdown[NS_CALENDAR_TALK]['*'] = array ('Calendar_talk');
 $wgNamespacePermissionLockdown[NS_LIMITED]['*'] = array ('Limited');
 $wgNamespacePermissionLockdown[NS_LIMITED_TALK]['*'] = array ('Limited_talk');
 # Lockdown - Access & Action for Sysops
 $wgNamespacePermissionLockdown[NS_PRIVAT_TALK]['*'] = array ('sysop');
 $wgNamespacePermissionLockdown[NS_PRIVAT]['*'] = array ('sysop');
 $wgNamespacePermissionLockdown[NS_CALENDAR]['*'] = array ('sysop');
 $wgNamespacePermissionLockdown[NS_CALENDAR_TALK]['*'] = array ('sysop');
 $wgNamespacePermissionLockdown[NS_LIMITED]['*'] = array ('sysop');
 $wgNamespacePermissionLockdown[NS_LIMITED_TALK]['*'] = array ('sysop');

Unable to Lock pages

I'm trying to lock all users except myself (I'm the only sysop on my wiki) from viewing a group of special pages, but I think I'm getting the syntax wrong or simply not understanding what I'm doing wrong.

I have the following namespace and language attempting to lock that namespace:

# create namespace
 define("NS_DM",100);
 define("NS_DM_TALK",101);
 $wgExtraNamespaces[NS_DM] = "DM";
 $wgExtraNamespaces[NS_DM_TALK] = "DM_talk";
# protect namespace
 $wgNamespaceProtection[NS_DM] = Array("editdm");
 $wgNamespacesWithSubpages[NS_DM] = true;
 $wgGroupPermissions['*']['editdm'] = false;
 $wgGroupPermissions['sysop']['editdm'] = true;

#restrict "read" permission to ???
 $wgNamespacePermissionLockdown[NS_DM]['*'] = array('sysop');
 $wgNamespacePermissionLockdown[NS_DM_TALK]['read'] = array('user');

#prevent inclusion of pages from that namespace
 $wgNonincludableNamespaces[] = NS_DM;
 $wgNonincludableNamespaces[] = NS_DM_TALK;

When I logout and search for and attempt to view the page, I am able to easily do both. (I understand extra measures must be taken to protect these pages from search, but will cross that bridge when I can lock the pages in the first place.) Any help would be greatly appreciated and of great assistance to me in the organization of my game.

67.188.252.135 08:43, 20 April 2009 (UTC)

Perusing the other questions answered on your talk page, I saw above you'd told someone not to mix NamespacePermissionLockdown with NamespaceProtection. I deleted the striked line above and it worked perfectly. Thanks for a great extension.  :) 67.188.252.135 07:48, 21 April 2009 (UTC)

Unable to download

1.13-link from ExtensionDistributor leads to an emtpy archive. — Preceding unsigned comment added by 91.77.129.200 (talk • contribs)

works in 1.15.0

just a heads up that the snapshot I had downloaded back in the days of 1.13.1 still works in 1.15.0 --Yonghokim 06:28, 20 June 2009 (UTC)

List of assignable permissions

In addition to Possible to restrict 'delete', I would like to know if there is a list of permissions which can be locked down.

As the above post states, the following permissions can be restricted, per namespace:

• read
• edit
• move
• createpage

Thank you, 192.75.172.1 16:01, 26 January 2010 (UTC)

Permissions list

Look to includes/DefaultPermissions.php for permissions list Alkvivad 01:51, 28 January 2010 (UTC)

Lock all Special: pages / for specific group only

$wgSpecialPageLockdown[Userlogin] = array('*');    # Without this, no-one can login anymore
$wgSpecialPageLockdown[Confirmemail] = array('*'); # Without, new users get error page after email confirmation
# add $wgSpecialPageLockdown's that you want, with names from includes/specials
$wgSpecialPageLockdown[] = array('mygroup');       # NEEDS TO BE THE LAST; locks all Special's not specified earlier!
# or: $wgSpecialPageLockdown[] = array('mygroup', 'othergroup', 'whatyouwant');

This is a simple and fast way giving optimal security for the Special: pages (also including rss/atom feeds), so you haven't missed any page there. Thereafter you can work and think on what rights other users than your group can regain. Use for the $wg mostly the names in directory .../includes/specials/ without "Special" and ".php", as a former poster found out: Extension_talk:Lockdown#Special_page_lockdown_is_extremely_case_sensitive --Cmi-ca 15:43, 30 January 2010 (UTC)

Token Based Authentication for Recent Changed

Ahoy, I'm on a project which uses mediawiki with lockdown. I need to read the rss feed of the recent changes page. All I'm asking for is a token based authentication system, so my reader can access the recent changes page using an additional GET parameter. Is there any hope? Best regards!

--85.182.87.13 17:56, 26 July 2010 (UTC)

Not working in 1.16.0

Hi I just upgraded from 1.13 to 1.16.0 and the extension does not seem to be working.

If I lock a namspace down to a particular group with the line

$wgNamespacePermissionLockdown[NS_LOCAL]['*'] = array('staff');

then users who are logged in but not a member of the group staff cannot read the page and get he misleading error

Permission error

The action you have requested is limited to users in one of the groups: *, Users. 

but users who are not logged in can read the page!

Cheers Anthony Worrall

It works nicely with version 1.15.5 but then I don't get the new vector skin :-(

Seconded - Overriding $wgGroupPermissions?

Please don't simply delete my comments because you disagree with me. Is it normal behavior that the the wgGroupPermissions should be overridden (simply turned off) by default when installing this extension?

I just installed it on a new copy of 1.16.0, and it doesn't appear to be working correctly - and it appears to be overriding $wgGroupPermissions. I had these lines before -

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;

With the extension included, anonymous users can once again edit the pages. Additionally, wild cards don't appear to work with $wgActionLockdown, since the below had no effect -

$wgActionLockdown['*'] = array('sysop');

I haven't tried any namespace protection like the above, but when disabling editting specifically -

$wgActionLockdown['edit'] = array('users')

I still see the Edit button as normal, but when I click it, I'm given no error and just a blank page. Is this normal behavior?

RE:Seconded - Overriding $wgGroupPermissions?

Please do NOT say an extension is not working merely because you do not understand how it works. If you send me a copy of your localsettings.php, I will fix it for you, but DO NOT say that an extension that is working for hundreds of sites doesn't work simply because YOU are having trouble making it work.

--jdpond 14:18, 8 November 2010 (UTC)

RE:RE:Seconded - Overriding $wgGroupPermissions?

Jdpond, You don't seem to understand. Surely this isn't normal behavior, that simply enabling the extension (require_once("$IP/extensions/Lockdown/Lockdown.php");) would cause these lines in LocalSettings.php to become invalid?

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;

The page for the Extension itself says, "you cannot *grant* permissions that have not been allowed by the build-in $wgGroupPermissions setting".

RE:RE:Seconded - Overriding $wgGroupPermissions? I can not reproduce your bug.

I just tested Lockdown in fresh installs of 1.15.5 and 1.16.0

Added this to localsettings of 1.15.5 and 1.16.0

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;
require_once( "$IP/extensions/Lockdown/Lockdown.php" );

In both 1.15.5 and 1.16.0 guests still can not edit, and you need to be registered to edit.

So I could not reproduce your bug.

How to Reproduce Bug

Can you try this on your fresh install of 1.16.0? Add the above lines like you previously did. Then, log into the wiki and leave the browser open and wait for your session to expire. (I've read this may be influenced by session.gc_maxlifetime and session.cache_expire in php.ini, but this doesn't seem to be the case for me.) After it expires, you should be able to edit the pages without being logged in. --134.161.225.55 17:50, 29 November 2010 (UTC)

Update: Here's a much quicker way to make your php session end, and to be able to see the bug. Find where your php sessions are being stored (this is session.save_path in phpinfo(), default /var/lib/php5/ on Ubuntu). Grep the files for your logged in username. Delete the session file for your session. Apache/PHP will recreate it as soon as you navigate to another page on your wiki - however, you should now be logged out AND able to edit pages without logging in. I'm beginning to wonder if this is more of a Mediawiki bug than a bug with this extension. --134.161.225.55 15:39, 2 December 2010 (UTC)

RE:RE:Seconded - Overriding $wgGroupPermissions?

Anonymous Northern Iowa Student,

I do not know where you have inserted these lines, or what you are trying to do. I do know that MANY use this extension under the environment that you are saying doesn't work. For example, see:

http://wiki.montcopa.org/MediaWiki
http://wiki.montcopa.org/TestWiki
http://wiki.montcpoa.org/ITS

Please be considerate in as much as this extension is not your work and that it does seem to be working for everyone BUT you, which is why the main page was reverted. MediaWiki is not a true content management system. If this doesn't work for you, may I suggest something like TWiki or Drupal? Additionally, the HALO extensions have a much easier to use GUI for setting permissions that may help you.

While you haven't posted what you're actually doing, I think the following may solve your problem since it explicitly sets privileges (sometimes even default ones which had a weird way of changing on me from release to release). Note in this case, only APPROVED users are allowed to edit etc. You may want to change to "$wgGroupPermissions['user'][$priv] = true;" if registration is all you are asking from your users (whereas they must not only register, but also be approved for our sites).

You would add the following to your localsettings.php:

/*
 * Set up the namespaces access for Lockdown Defaults
 * Our wikis generally require user registration to access more than the first page
 * Additionally, namespaces are widely used to protect information that is limited to users
 * who belong to the groups with the same name as the namespaces.
 * this sets everything up accordingly.
*/

$LockdownDefaultPrivileges = array(
					'read','edit','move','delete','create','createpage',
					'createtalk','upload','reupload','reupload-shared','minoredit'
				);

# Implicit group for all visitors
$wgGroupPermissions['*']['createaccount'] = true;
foreach ($LockdownDefaultPrivileges as $priv) $wgGroupPermissions['*'][$priv] = false;

# Implicit group for all logged-in accounts
$wgGroupPermissions['user']['createaccount'] = true;
foreach ($LockdownDefaultPrivileges as $priv) $wgGroupPermissions['user'][$priv] = false;

# Approved accounts
foreach ($LockdownDefaultPrivileges as $priv) $wgGroupPermissions['approved'][$priv] = true;

# Sysops
foreach ($LockdownDefaultPrivileges as $priv) $wgGroupPermissions['sysop'][$priv] = true;

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

$wgGroupPermissions['*']['read'] = true;

RE:RE:Seconded - Overriding $wgGroupPermissions?

This is the extent of my configuration -

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

# Only allow registered users to edit :
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;

# Require users to confirm their e-mail address before editing
$wgEmailConfirmToEdit = false;

# Disable account creation
$wgGroupPermissions['*']['createaccount'] = false;

When the extension is not loaded, users must be logged in to edit, and they cannot create new accounts (this is true if I comment out the first line I listed above). Simply loading the extension causes the $wgGroupPermissions and $wgEmailConfirmToEdit lines listed above to no longer have any affect (anonymous users can create accounts and edit pages). My understanding, from reading the description on the main page, is that this should not be the case. Is that incorrect?

Same Behaviour

I see the same behaviour as described before. As the readme header in Lockdown.php says explicitly "NOTE: you cannot GRANT access to things forbidden by $wgGroupPermissions. You can only DENY access granted there." I am confused, too. Is this behaviour a bug, or is it intended? If the latter is the case, the documentation may be misleading. At the moment, I regard it as a bug and will file it at bugzilla. --Splinter 17:54, 17 November 2010 (UTC)

Thanks for the following up with Bugzilla, Splinter... good idea, I didn't think of that. I think it is related to the session expiring somehow. I saw this behavior when I first enabled the extension, then it's been fine for a few days. Now, when my authenticated session with my Mediawiki install expired (no longer logged in), I could edit and the changes showed as my IP... I could edit without logging in even after clearing my cache, but not after I deleted all cookies. --134.161.225.55 17:22, 23 November 2010 (UTC)

How can I hide the restricted link

Hi ! Can anyone help with disabling 'Special-pages' link in the toolbox ? I have just uset Lockdown (thanks - it's a great job), but users with no access still can see the link. Is there possibile to "turn off" the link for users/groups with no rights ?

This is not the right place to ask that question. The link is defined in the skin. You might want to change you skins/MonoBook.php and wrap the part with recentchangeslinked with a check, if the user is logged in. Your question has although nothing to do with this extension. Search for "customizing mediawiki skin". --85.182.80.114 11:55, 16 August 2010 (UTC)

Sorry. Anyway Thanks for response