Extension talk:Lockdown

Jump to navigation Jump to search

About this board

Archive 1

Namespace lockdown doesn't work correctly in MW 1.31

Maude's Ideology (talkcontribs)

Use this instead, in your LocalSettings.php, to limit the NS_PRIVATE and NS_PRIVATE_TALK namespaces to WikiSysop and User2.

$wgHooks['ParserBeforeStrip'][] = 'LockDownFunction';
function LockDownFunction( &$parser, &$text, &$strip_state ) {
        global $wgUser;
        $title = $parser->getTitle();
        $namespace = $title->getNamespace();
        if ( $namespace === NS_PRIVATE || $namespace === NS_PRIVATE_TALK ) {
                $user = $parser->getUser();
                $userName = $user->getName();
                $allowed = array(
                if ( in_array( $userName, $allowed )
                        || in_array( $wgUser, $allowed )
                ) {
                        return true;
                } else {
                        die("Access denied");
2003:D2:DBC6:8A00:ECEA:9E8D:EF51:E302 (talkcontribs)

This is Great but you have to reverse the order in in_array for it to work

in_array( $userName, $allowed )

should to be

in_array( $allowed, $userName )

Thank you so much ! I have been so tired of deprecated Extensions that dont work.

BabunaLaguna (talkcontribs)
## //Restrict namespace access to group privat 
$wgHooks['ParserBeforeStrip'][] = 'LockDownFunction';
function LockDownFunction( &$parser ) {
    $title = $parser->getTitle(); 
    $namespace = $title->getNamespace(); 
    //Groups in here are allowed to access
    $allowedgroups = 'privat'; 
    //Restricted namespaces
    $wgLockedNamespaces = array( '3000', '3001' ); 
    if ( in_array($namespace, $wgLockedNamespaces) ) { 
        $user = $parser->getUser(); 
        $userGroups = $user->getGroups(); 
        if ( !in_array( $allowedgroups, $userGroups )) { 
            die("<h1>Access denied, you dont have the necessary permissions to access this namespace.</h1>");
        return true;
Reply to "Namespace lockdown doesn't work correctly in MW 1.31" (talkcontribs)

When i put in my LocalSettings.php the expresison "wfLoadExtension( 'Lockdown' );", and i try access the main page, the server returns "ERROR 500". (talkcontribs)

lockdown is incompatible with WM 1.30, it seems accesscontrol extension either

Reply to "MW 1.31 - Error 500 with Lockdown" (talkcontribs)

I am trying to get Lockdown to work on MW 1.30. After installing the git master, it show up under Special:Version. When trying to limit read access to a custom namespace with this config:

$wgNamespacePermissionLockdown[3002]['read'] = array('sysop');

actually the main namespace is limited to sysops and the custom namespace is not locked down. I was not able to lockdown the custom namespace at all. Any suggestions? Thx, Marc

Bevenson (talkcontribs)

Were you able to get this to work?

Reply to "Working on MW 1.30?"

Issues in MW 1.27.4: Namespace completely ignored, always affects main and main talk only

Redeemer (talkcontribs)

I downloaded and installed the MW 1.27 version in MW 1.27.4. Either, I'm not understanding the extension properly, or it does not work.

Minimal and pointless example: I'm trying allow editing in namespace 2 (user) for bots only, so I added

$wgNamespacePermissionLockdown[2]['edit'] = array('bot');

to the end of my LocalSettings.php as the only Lockdown-related line. As the result, only bots are allowed to edit namespaces 0 (main) and 1 (talk) while everyone is still able to edit the user namespace. Generally, no matter what namespace I enter, Lockdown always affects namespace 0 and 1 only.

Reply to "Issues in MW 1.27.4: Namespace completely ignored, always affects main and main talk only"
TheRebel~mediawikiwiki (talkcontribs)

I was having problem with locking down certain special pages based on user groups with Lockdown on MW 1.17 and 1.16. Here is a solution that doesn't need Lockdown at all, just enter this in your LocalSettings.php:

function SpecialPageBlock(&$list){
global $wgUser;
if (in_array('sysop', $wgUser->getGroups()) == 0){
)as $i){unset($list[$i]);}}
return true;}

The example above limits access to the pages listed in the array to the 'sysop' group, by removing the pages from the rest of the groups. The best thing in this solution is that the pages in the array won't even show up on the SpecialPages.

For some reason Random and MostLinkedPages couldn't be disabled this way, any ideas why?

This post was posted by TheRebel~mediawikiwiki, but signed as TheRebel. (talkcontribs)

Thanks! A much better solution. People don't even know what they're missing. (talkcontribs)

This works perfectly. This should be linked to from restricting access pages. Thanks a bunch.

Frantik (talkcontribs)

Here is a function which allows you to specify various user groups and also whitelist pages, as opposed to having to list every single page to block.

function SpecialPageBlock(&$list)
	global $wgUser;
	$allowedGroups = array(
	$whiteList = array(

	$allowed = false;
	$userGroups = $wgUser->getGroups();	
	foreach($allowedGroups as $group)
		if (in_array($group, $userGroups))
			$allowed = true;
	if (!$allowed)			
		foreach($list as $key => $specialPage)
			if (!in_array($key, $whiteList))
	return true;

Kghbln (talkcontribs)

Thanks a lot for sharing! Much apprechiated!

Reply to "Locking down special pages"
Summary by Kghbln

Docu was updated.

Alvarosaurus (talkcontribs)

Hi, it appears that Lockdown.php has been deleted from the 1.27 version.

Kghbln (talkcontribs)
JamesJeko (talkcontribs)

Hi all,

When I try to restrict (validate) perrmision on a specific namespace, it does not work. But it still works on other permissions such as (Edit, Delete, Read). So, is there any way to solve these problems? thanks

Reply to "Lockdown (validate) permission"
Calion (talkcontribs)
Kghbln (talkcontribs)

You can. That's not even Lockdown specific.

Calion (talkcontribs)

To the Manual page?

Reply to "Error in Page"

lockdown "Difference between revisions" Page

1 (talkcontribs)
Reply to "lockdown "Difference between revisions" Page"
Kghbln (talkcontribs)

-- Originally posted by --

I should apologize because the only reason my problem appeared resolved after I installed REL1_27 was that I had Lockdown extension commented out in LocalSettings.

So, today I tested it again and preview did not work. Namely, request to /w/api.php with this POST data:




title:<Title here>

text:<Content here>






fails with the following response: {"error":{"code":"readapidenied","info":"You need read permission to use this module","docref":"See http://doc.ifcg.ru/w/api.php for API usage"}}

Non-default part of my LocalSettings follows:

Hope this will help.

Kghbln (talkcontribs)

-- Originally posted by Rrosenfeld --

Same problem here.

I use REL-1.27 (0d8aa13) with a private wiki (access only for logged in users).

On API access I get the message "readapidenied".

The problem is, that checkExecutePermissions() in ApiMain.php has $user->isAllowed( 'read' ) unset, which results in the above error.

But I have no idea, what I have to do to get this set here.

Kghbln (talkcontribs)

Cannot this be overcome by assigning the bot to a usergroup which is allowed to edit? If not an issue report should be created at Phabricator and linked back and forth to this thread.

Kghbln (talkcontribs)

I guess this is now tracked with task T148582.

Zoglun (talkcontribs)
Kghbln (talkcontribs)

Thanks for doing a field test. The issue reports are linked. To make developers aware which do not necessarily see these threads here ... ;) (talkcontribs)

Saying to that using Lockdown causes 'writeapidenied' You're not allowed to edit this wiki through the API error. So in MW 1.27 VisualEditor extension can`t save page edition.

Kghbln (talkcontribs)

As a matter of fact the MultimediaViewer extension also exits with readapidenied for MW 1.27.1

Kghbln (talkcontribs)

This is still an issue with latest code on REL1_27. Thus I have adjusted task T148582 accordingly. Let's hope for a quick fix.

Kghbln (talkcontribs)
Kghbln (talkcontribs)

Great, now that T148582 will be resolved by doing a backport to MediaWiki core with change 325566 all we have to do is wait for the MW 1.27.2 release. (talkcontribs)

I have having this same problem and I am using 1.27.2 and the latest REL1_27

Kghbln (talkcontribs)

I only get this for the second action the api tries to perform so effectively bulk uploads do not work. Moreover I am the only clown here actually making people aware on Phabricator so that's probably why nothing gets moving. (talkcontribs)

Hi, I came across this issue and decided to upgrade to 1.27.3. We still seem to be encountering the issue with MsUpload. Without lockdown, logged in users can upload files fine using MsUpload. Once Lockdown is enabled, I receive the "permission denied" error, regardless of role. Is there a setting I am missing or is this still an ongoing bug? Thanks!

Kghbln (talkcontribs)

It is indeed an ongoing bug with nobody dealing with it. MsUpload can according to my testing only upload one file at a time, which indeed makes it pretty much useless.

Loman87 (talkcontribs)

Hi, any news about this issue? Is there any chance to solve it if I upgrade to 1.28?



Kghbln (talkcontribs)

If it is broken with 1.27 it will also be broken with 1.28 and later. Apart from that any news. It seems to be not important since hardly anybody joins the conversion on task T148582.

Loman87 (talkcontribs)

Ok, thanks for the information. Is there anhything to do to press to solve the issue? On wikiapiary this extension results to be used by 504 wikis...they don't seem few to me!



Kghbln (talkcontribs)

Perhaps it is just a matter of telling on phabricator that you have the same issue. Also noting the usage my be an argument to bring forward, too. That's 504 wikis not even counting private wikis. From my experience the ratio is 50% to 50%.

If I am the only one voicing concerns and requests ...

Reply to "Not working in MW 1.27 via API"