Open main menu

Extension talk:Lockdown

About this board


Archives
Archive 1


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){
foreach(array('Uncategorizedimages','Unusedimages','Withoutinterwiki', 
'Newimages','Listfiles','MIMEsearch','FileDuplicateSearch','Filepath', 
'Booksources','Mostimages','Tags','Disambiguations','BrokenRedirects','Deadendpages',
'DoubleRedirects','Longpages','Ancientpages','Lonelypages','Fewestrevisions','Protectedpages',
'Protectedtitles','Shortpages','Uncategorizedcategories','Uncategorizedpages','Uncategorizedtemplates',
'Unusedcategories','Unusedtemplates','Wantedcategories','Wantedfiles','Wantedpages','Wantedtemplates',
'Allpages','Prefixindex','Categories','Listredirects','Activeusers','Contributions',
'Log','Newpages','Recentchanges','Recentchangeslinked','Listgrouprights','Listusers',
'Popularpages','Statistics','Allmessages','Version','LinkSearch','Random','Randomredirect',
'Mostlinkedcategories','Mostlinkedpages','Mostlinkedtemplates','Mostcategories','Mostrevisions',
'Export','Whatlinkshere'
)as $i){unset($list[$i]);}}
return true;}
$wgHooks['SpecialPage_initList'][]='SpecialPageBlock';

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.

203.118.164.219 (talkcontribs)

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

50.137.193.149 (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(
		'sysop',
	);
	
	$whiteList = array(
		'Userlogin',
		'Userlogout',
		'Search',
		'Preferences',
		'ChangePassword',
	);

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

$wgHooks['SpecialPage_initList'][]='SpecialPageBlock';
Kghbln (talkcontribs)

Thanks a lot for sharing! Much apprechiated!

AssetDenmark (talkcontribs)

Thanks - i had to add 'ConfirmEmail', 'CreateAccount', to the $whitelist otherwise it is working for me!

Also i got this to work.. so LockDown is not totally useless for me... ;-)

# Lockdown start

wfLoadExtension( 'Lockdown' );

$wgNamespacePermissionLockdown['*']['edit'] = [ 'sysop' ];

      

You can then add special groups and permissions to flesh groups that can 'read' and/or 'edit' namespaces... appears to be working!


Reply to "Locking down special pages"

Extension:Lockdown not working - $wgActionLockdown and others..?

2
AssetDenmark (talkcontribs)

I there a bug in this - I am trying to restrict the export function (entirely limit the range of special pages) in a simple way... but it seems like nothing is working for me. (I did try to mess with the $wgGroupPermissions - but I backed that out totally - and now lockdown is the only extension!

# Lockdown start

wfLoadExtension( 'Lockdown' );

Seems like this installed correct. But neither of these restricts 'user' from going to the (special page) export page...


$wgActionLockdown['Export'] = [ 'sysop' ];

$wgSpecialPageLockdown['Export'] = [ 'user' ];


and this is what I tired initially... after/while I was logged in as sysop..

$wgNamespacePermissionLockdown[NS_SPECIAL]['*'] = [ 'sysop' ];


(version 1.32.0)

AssetDenmark (talkcontribs)

Thanks to this Topic:Qan3neqhnccfkt5p - i can now exclude users from Specialpages... please look at that topic for my comments!

$wgNamespacePermissionLockdown['*']['edit'] = [ 'sysop' ];

IS working fine for me.. and I can also add namespacve permissions to selected users... like this.


$wgNamespacePermissionLockdown[NS_Baggrund]['read'] = array('user');

$wgNamespacePermissionLockdown[NS_Baggrund_TALK]['*'] = array('user');


Tip you can also add a new user group, that 'sysop' can then assigned. Say I have some namespace material that should only be available to 'user' (registered), and then some that should be available it I give permission. To create a new group, this group will be on the you must have lines (one for each group) like this in the localsettings.php:

$wgGroupPermissions['your-permisison-group']['read']   = false;

Reply to "Extension:Lockdown not working - $wgActionLockdown and others..?"

Lockdown and VisualEditor - can't edit protected pages

20
Ckoerner (talkcontribs)

I have a wiki running 1.23wmf11 and the latest build of VisualEditor, the WYSIWYG editor from Wikimedia. It uses a node.js-based parser to round-trip wikitext called Parsoid.

I have defined a few custom name spaces and enabled VisualEdtior for those name spaces. Everything is working as intended.

If I use $wgNamespacePermissionLockdown to define read and edit rights for user groups VisualEditor does not work.

Instead I'm prompted with a "Error loading data from server: parsoidserver-http-bad-status: 500."

Editing the page with WikiEditor works as intended.

node spits out the following when the attempt to edit is made.

starting parsing of localhost:DBC:Cache_Shadowing_Stop/Start_Suspend/Resume
 ERROR in localhost:DBC:Cache_Shadowing_Stop/Start_Suspend/Resume with oldid: 123915
 Stack trace: Error: API response is missing query for: DBC:Cache_Shadowing_Stop/Start_Suspend/Resume
  at TemplateRequest._handleJSON (/var/www/Parsoid/lib/mediawiki.ApiRequest.js:270:11)
  at TemplateRequest.ApiRequest._handleBody (/var/www/Parsoid/lib/mediawiki.ApiRequest.js:192:7)
  at TemplateRequest.ApiRequest._requestCB (/var/www/Parsoid/lib/mediawiki.ApiRequest.js:149:8)
  at Request.self.callback (/var/www/Parsoid/node_modules/request/request.js:129:22)
  at Request.EventEmitter.emit (events.js:98:17)
  at Request.<anonymous> (/var/www/Parsoid/node_modules/request/request.js:873:14)
  at Request.EventEmitter.emit (events.js:117:20)
  at IncomingMessage.<anonymous> (/var/www/Parsoid/node_modules/request/request.js:824:12)
  at IncomingMessage.EventEmitter.emit (events.js:117:20)
  at _stream_readable.js:920:16

It sounds like the Lockdown extension is somehow getting in the way of Parsoid and the MediaWiki api to make it's calls.

While VisualEditor is not the default editor for MediaWiki, its active development and future roadmap seem to indicate that it will be a preferred way to edit wiki pages for many editors. Any inputs and thoughts would be appreciated.

47.19.118.253 (talkcontribs)

Hi, did you ever find a solution for this?

I'm running the Lockdown extension on MediaWiki 1.24.1 with the latest build of VisualEditor and I'm running into the same behavior where I'm unable to edit protected namespaces using VisualEditor.

Any help would be greatly appreciated!

89.216.28.24 (talkcontribs)

I am having the same issue. Pages that are under a namespace which is locked by Lockdown can't be edited with VisualEditor. WikiEditor works just fine.

Monic abc (talkcontribs)

I have the same problem, but I use HaloACL extension. Is there any chance to fix this?

Andrew Garrett (WMF) (talkcontribs)
89.216.28.24 (talkcontribs)

Enabled cookies, still can't get VisualEditor to work on protected pages with Lockdown.

I created a new group called testgroup with a tool AccessControlPanel (frontend to Lockdown) and visited the page testgroup:Main_page in a browser where I was logged in (Firefox) and in another browser (Chrome). In first browser, I saw the edit button to edit the page in VisualEditor and then I got error (js alert dialog) "novenamespace: VisualEditor is not enabled in namespace 138" and after a reload, the VisualEditor Tab button disappeared.

In Chrome the page was restricted and I needed to log in to be able to see it, as expected.

If I manually create a namespace and if I restrict the namespace (read) to a user group in LocalSettings.php, every page created in that namespace can't be edited with VisualEditor. Only with WikiEditor.

Editing any other page that isn't restriced with Lockdown can be edited with VisualEditor.

163.244.62.183 (talkcontribs)

BUMP

I have this identical issue using MW 1.25, parsoid 0.3.0 and the latest drops of Visual Editor and Lockdown.

Did anyone reach a solution for this?

Gino3008 (talkcontribs)

Hello everyone.

We just have the SAME issue with Visual Editor and Lockdown.

Did anyone find a solution ??

Is this an inevitable problem with lockdown ?

We've been looking for a solution since all the day and nothing's working.

We've trying every solutions posted on the internet and .. no.

Please is there a god on this earth able to help us ??

Thank you

HermannSchwärzler (talkcontribs)

Hi everybody,

I think the problem is solved in newer Versions of MW and VE, as in my Installation of

MediaWiki 1.27.0-wmf.11 and

VisualEditor 0.1.0 (a6e24f4) 00:37, 1 February 2016

with VisualEditor enabled for the "Project" Namespace, which is write protected by Extension:Lockdown I am able to successfully edit those protected pages with VE. I have a Parsoid-server running on an a private backend-network and I am doing cookie-forwarding.

The Parsoid-server is a git clone from the beginning of February 2016.

Greetings

Hermann

Dieudo (talkcontribs)

Hi,

Encouraged by Hermann's example, I tried with latest night (2016.02.24) builts of every bit of software involved but I still get this message :

Erreur lors du chargement des données du serveur : 500: parsoidserver-http: HTTP 500. Voulez-vous réessayer ?

Thanks for any help.

HermannSchwärzler (talkcontribs)

Hi @Dieudo,

this looks like a configuration-error or something. Your parsoid-server had some kind of problem and answered with HTTP code 500 ("Internal Server Error").

How do you start parsoid?

And what do you see it output when you run it with

parsoidConfig.debug = true;

in you localsettings.js?

Greetings

Hermann

Dieudo (talkcontribs)

Actually it looks like there's a problem with my lockdown configuration alone. I'll have to check that first. Thx for your help Hermann : )

Dieudo (talkcontribs)

The error I get now is :

 Fatal error: Call to a member function getId() on a non-object in .../extensions/Lockdown/Lockdown.php on line 163
HermannSchwärzler (talkcontribs)

Sorry, I forgot to mention that. There seems to be a bug in Lockdown in combination with MW 1.27 - see https://phabricator.wikimedia.org/T127456

Just add this code before line 162:

 if ( !$wgUser ) {
        return true;
 }
Dieudo (talkcontribs)

Thank you Hermann !

This does the trick : )

However, it does it only if when including this line in LocalSettings.php :

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

I wonder what to do to be able to use both Lockdown and VisualEditor on a wiki not private.

Any idea ?

Textform (talkcontribs)

My solution was, not to load Lockdown, if the request comes from the localhost. In an other configuration I had to take the non-local IP-adress of the server

if ( $_SERVER['REMOTE_ADDR'] != '127.0.0.1' ) {
require_once( "extensions/Lockdown/Lockdown.php" );
}

Additionaly the namespaces had to be activated for VE with $wgVisualEditorAvailableNamespaces

$wgVisualEditorAvailableNamespaces = array( 
NS_MAIN     => true,
NS_USER     => true,
NS_HELP     => true,
NS_PROJECT  => true,
NS_MYCUSTOMNAMESPACE  => true,
);

And read and edit permissions had to be given globally if request came from localhost

if ( $_SERVER['REMOTE_ADDR'] == '127.0.0.1' ) {
$wgGroupPermissions['*']['read'] = true;
$wgGroupPermissions['*']['edit'] = true;
}
217.6.132.212 (talkcontribs)

Hi i have the same Problem here.

Where do you put the if Arguments? In the LocalSettings.php?

Kghbln (talkcontribs)

Yes, "LocalSetting.php"

109.199.10.165 (talkcontribs)

Hi guys,

I'm dealing with the same issue. If Lockdown is enabled, then VE refuses to save *any* page dispalying message "Permission denied". If I disable Lockdown by commenting out this section:

if ( $_SERVER['REMOTE_ADDR'] != '127.0.0.1' AND $_SERVER['REMOTE_ADDR'] != '::1' ) {

require_once "extensions/Lockdown/Lockdown.php";

}

Then VE works as hell.

I'm using the latest stable mediawiki, parsoid, Lockdown and VE.

My LocalSettings includes also:

$wgVisualEditorAvailableNamespaces = array(

NS_MAIN     => true,

NS_USER     => true,

NS_HELP     => true,

NS_PROJECT  => true,

NS_RESTRICTED => true

);

if ( $_SERVER['REMOTE_ADDR'] == '127.0.0.1' OR $_SERVER['REMOTE_ADDR'] == '::1' ) {

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

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

} else {

# The following permissions were set based on your choice in the installer

$wgGroupPermissions['*']['createaccount'] = false;

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

}

Do you have any idea how this issue can be fixed?

Thanks in advance.

Maciej

Marco.malavolti (talkcontribs)

Mediawiki: v1.32.1

NodeJS: v10.15.3

Distribution: Debian GNU/Linux 9.8 (stretch)


Parsoid + VisualEditor + Lockdown (with SSL):

1) sudo apt install xs-utils

2) sudo wget https://nodejs.org/dist/v10.15.3/node-v10.15.3-linux-x64.tar.xz -O /usr/local/src/nodejs-10.15.3.tar.xz

3) sudo tar xf /usr/local/src/nodejs-10.15.3.tar.xz -C /usr/local/ --stript-components 1

4) sudo npm install -g parsoid

5) sudo vim /usr/local/lib/node_modules/parsoid/config.yaml

------ START config.yaml -------

services:

  - module: lib/index.js

    entrypoint: apiServiceWorker

    conf:

        mwApis:

        - uri: 'http://{{ fqdn }}/{{ mw_wiki_dir_name }}/api.php'

        # - uri: 'https://{{ fqdn }}/{{ mw_wiki_dir_name }}/api.php' # If you redirect all HTTP traffic to HTTPS

        # - uri: 'http://{{ other_fqdn }}/{{ mw_wiki_dir_name }}/api.php'

------ END config.yaml -------


6) sudo vim /etc/systemd/system/parsoid.service


----- START parsoid.service -----

[Unit]

Description=Mediawiki Parsoid web service on node.js

Documentation=http://www.mediawiki.org/wiki/Parsoid

Wants=local-fs.target network.target

After=local-fs.target network.target


[Install]

WantedBy=multi-user.target

[Service]

Type=simple

User=root

Group=root

WorkingDirectory=/usr/local/lib/node_modules/parsoid

ExecStart=/usr/local/bin/node /usr/local/lib/node_modules/parsoid/bin/server.js

KillMode=process

Restart=on-success

PrivateTmp=true

StandardOutput=syslog

----- END parsoid.service -----


7) sudo service parsoid start (this load parsoid on port 8000)

8) sudo systemctl enable parsoid

9) sudo apt install stunnel

10) sudo vim /etc/stunnel/parsoid.conf


----- START parsoid.conf -----

cert = /etc/ssl/certs/{{ fqdn }}.crt

key = /etc/ssl/private/{{ fqdn }}.key

CAfile = /etc/ssl/certs/ca-certificates.crt


[parsoid]

accept  = 8143

connect = 8000

----- END parsoid.conf -----


11) sudo vim /etc/default/stunnel4

----- START stunnel4 -----

...

# Change to one to enable stunnel automatic startup

ENABLED=1

...

----- END stunnel4 -----


12) sudo service stunnel4 restart (now you can reach parsoid on 8143)

13) sudo vim .../w/LocalSettings.php

----- START LocalSettings.php -----

...

// NEW Namespaces

define("NS_NEW_1", 3000);

define("NS_NEW_1_TALK", 3001);


$wgExtraNamespaces[NS_NEW_1]                  = "NEW1";

$wgExtraNamespaces[NS_NEW_1_TALK]       = "NEW1_talk";          # Note underscores in the namespace name.

$wgNamespaceProtection[NS_NEW_1]            = array( 'edit-new1' );      # "edit-new1" required to edit NEW1:pages

$wgNamespaceProtection[NS_NEW_1_TALK] = array( 'edit-new1-talk' ); # "edit-new1-talk" required to edit NEW1_talk:pages

$wgNamespacesWithSubpages[NS_NEW_1]  = true;        # subpages enabled for the NEW1 namespace

$wgGroupPermissions['new1']['edit-new1']           = true;     # permission "edit-new1" granted to users in the "new1" group

$wgGroupPermissions['new1']['edit-new1-talk']    = true;     # permission "edit-new1-talk" granted to users in the "new1" group

$wgContentNamespaces[]                            = NS_NEW_1; #prevent inclusion of pages from that namespace

$wgNonincludableNamespaces[]                 = NS_NEW_1;

$wgNonincludableNamespaces[]                 = NS_NEW_1_TALK;


wfLoadExtension( 'Lockdown' );

#restrict all permissions on pages with namespace "NEW" to users belonging to 'new1' group

$wgNamespacePermissionLockdown[NS_NEW_1]['*'] = array('new1');

$wgNamespacePermissionLockdown[NS_NEW_1_TALK]['*'] = array('new1');


wfLoadExtension( 'VisualEditor' );


// Enable by default for everybody

$wgDefaultUserOptions['visualeditor-enable'] = 1;


// Don't allow users to disable it

$wgHiddenPrefs[] = 'visualeditor-enable';


$wgVirtualRestConfig['modules']['parsoid'] = array(

    // URL to the Parsoid instance

    // Use port 8142 if you use the Debian package

    'url' => 'https://{{ fqdn }}:8143',

    'forwardCookies' => true,

);


$wgVisualEditorAvailableNamespaces = [

    NS_MAIN => true,

    NS_USER => true,

    NS_HELP => true,

    NS_NEW_1 => true,

];

...

----- END LocalSettings.php -----


Parsoid + VisualEditor (without SSL):

1) sudo apt install xs-utils

2) sudo wget https://nodejs.org/dist/v10.15.3/node-v10.15.3-linux-x64.tar.xz -O /usr/local/src/nodejs-10.15.3.tar.xz

3) sudo tar xf /usr/local/src/nodejs-10.15.3.tar.xz -C /usr/local/ --stript-components 1

4) sudo npm install -g parsoid

5) sudo vim /usr/local/lib/node_modules/parsoid/config.yaml

------ START config.yaml -------

services:

  - module: lib/index.js

    entrypoint: apiServiceWorker

    conf:

        mwApis:

        - uri: 'http://{{ fqdn }}/{{ mw_wiki_dir_name }}/api.php'

        # - uri: 'https://{{ fqdn }}/{{ mw_wiki_dir_name }}/api.php' # If you redirect all HTTP traffic to HTTPS

        # - uri: 'http://{{ other_fqdn }}/{{ mw_wiki_dir_name }}/api.php'

------ END config.yaml -------


6) sudo vim /etc/systemd/system/parsoid.service


----- START parsoid.service -----

[Unit]

Description=Mediawiki Parsoid web service on node.js

Documentation=http://www.mediawiki.org/wiki/Parsoid

Wants=local-fs.target network.target

After=local-fs.target network.target


[Install]

WantedBy=multi-user.target

[Service]

Type=simple

User=root

Group=root

WorkingDirectory=/usr/local/lib/node_modules/parsoid

ExecStart=/usr/local/bin/node /usr/local/lib/node_modules/parsoid/bin/server.js

KillMode=process

Restart=on-success

PrivateTmp=true

StandardOutput=syslog

----- END parsoid.service -----


7) sudo service parsoid start (this load parsoid on port 8000)

8) sudo systemctl enable parsoid

9) sudo apt install stunnel

10) sudo vim .../w/LocalSettings.php


----- START LocalSettings.php -----

...

// NEW Namespaces

define("NS_NEW_1", 3000);

define("NS_NEW_1_TALK", 3001);


$wgExtraNamespaces[NS_NEW_1]                  = "NEW1";

$wgExtraNamespaces[NS_NEW_1_TALK]       = "NEW1_talk";          # Note underscores in the namespace name.

$wgNamespaceProtection[NS_NEW_1]            = array( 'edit-new1' );      # "edit-new1" required to edit NEW1:pages

$wgNamespaceProtection[NS_NEW_1_TALK] = array( 'edit-new1-talk' ); # "edit-new1-talk" required to edit NEW1_talk:pages

$wgNamespacesWithSubpages[NS_NEW_1]  = true;        # subpages enabled for the NEW1 namespace

$wgGroupPermissions['new1']['edit-new1']           = true;      # permission "edit-new1" granted to users in the "new1" group

$wgGroupPermissions['new1']['edit-new1-talk']    = true;      # permission "edit-new1-talk" granted to users in the "new1" group

$wgContentNamespaces[]                            = NS_NEW_1; #prevent inclusion of pages from that namespace

$wgNonincludableNamespaces[]                 = NS_NEW_1;

$wgNonincludableNamespaces[]                 = NS_NEW_1_TALK;


wfLoadExtension( 'Lockdown' );

#restrict all permissions on pages with namespace "NEW" to users belonging to 'new1' group

$wgNamespacePermissionLockdown[NS_NEW_1]['*'] = array('new1');

$wgNamespacePermissionLockdown[NS_NEW_1_TALK]['*'] = array('new1');


wfLoadExtension( 'VisualEditor' );


// Enable by default for everybody

$wgDefaultUserOptions['visualeditor-enable'] = 1;


// Don't allow users to disable it

$wgHiddenPrefs[] = 'visualeditor-enable';


$wgVirtualRestConfig['modules']['parsoid'] = array(

    // URL to the Parsoid instance

    // Use port 8142 if you use the Debian package

    'url' => 'http://127.0.0.1:8000',

    'forwardCookies' => true,

);


$wgVisualEditorAvailableNamespaces = [

    NS_MAIN => true,

    NS_USER => true,

    NS_HELP => true,

    NS_NEW_1 => true,

];

Reply to "Lockdown and VisualEditor - can't edit protected pages"
Serek (talkcontribs)

I am trying to set:


$wgNamespacePermissionLockdown[0]['createpage'] = array( 'bureaucrat', 'sysop' );


but it does not seem to work. Is it possible at all to limit page creation only? MW 1.31.1

AhmadF.Cheema (talkcontribs)
Reply to "createpage only permissions?"

Namespace lockdown doesn't work correctly in MW 1.31

5
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(
                        'WikiSysop',
                        'User2'
                );
                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;
    }
}
AhmadF.Cheema (talkcontribs)

The directly above method noted by User:BabunaLaguna does not work when submitting an edit (&action=submit) to the protected namespace and instead throws out the "Access denied..." message at the end.

141.84.65.170 (talkcontribs)

Tested MW 1.31.0 on PHP 7.2.12 with Lockdown (dbd06b7). Wanted to lock one namespace and talk (198 and 199). This locked all pages in the wiki! But when using array_fill in LocalSettings.php, it seems to work:


$defaultreadall['read'] = array('*');

$wgNamespacePermissionLockdown = array_fill(0,2010,$defaultreadall);

$wgNamespacePermissionLockdown[NS_INTERNAL]['read'] = array('MyAllowedGroup');

$wgNamespacePermissionLockdown[NS_INTERNAL_TALK]['read'] = array('MyAllowedGroup');


The problem was, that the Lockdown-hook sees the global array wgNamespacePermissionLockdown as a collapsed one with empty indexes removed. Instead of [198, 192] it was only [0,1] as array keys.

Reply to "Namespace lockdown doesn't work correctly in MW 1.31"

Use of lowercase letter in compound words of special page names

2
Deltaray3 (talkcontribs)

Just something to note that wasn't clear at first until I read this talk page which gives some more examples. For some special page names, only the first character is capitalized and the rest of the word is all lowercase. For example, the page is called "Special:ListUsers" in MediaWiki, but you need to call it "Listusers" (lowercase u) in the config file for it to work. This contradicts the naming of the special pages by Mediawiki. Thanks for this extension.

Kghbln (talkcontribs)

Thanks for the note. However this is already documented on the extension's page There is also a difference between internal naming and user facing naming. Yeah, indeed a bit complicated at the beginning.

Reply to "Use of lowercase letter in compound words of special page names"
179.111.167.151 (talkcontribs)

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

112.115.94.118 (talkcontribs)

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

Reply to "MW 1.31 - Error 500 with Lockdown"
79.213.181.124 (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

1
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"
Summary by Kghbln

Docu was updated.

Alvarosaurus (talkcontribs)

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

Kghbln (talkcontribs)
Return to "Lockdown" page.