Extension talk:Lockdown

Jump to navigation Jump to search

About this board

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

Reply to "Working on MW 1.30?"

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"
AhmadF.Cheema (talkcontribs)

When using the Advanced tab in Special:Search the "Search in namespaces:" section only shows the namespaces which had been protected through Extension:Lockdown (i.e.namespaces included in $wgNamespacePermissionLockdown variable).

The bug was observable for users with permissions granted for these lockdown namespaces as well as anonymous users.

  • Tested on: MediaWiki v1.28.2 (438c3d6) - 00:03, 1 May 2017
  • On extension branches: master, REL1_29, REL1_28

Fortunately, the problem does not exist for REL1_27.


On further investigation with individual commits for finding out which commit caused the breaking changes used the Rel1_28 commit history.

Special:Search works fine up-to-the commit, Merge "The parameter to the SearchableNamespaces hook handler needs to be a…

git checkout b19a0a60a476ddbf5344395b339e928729c11f54

For whatever reason, the Special:Search bug appears in the very next commit, Consolidate hook handler code

git checkout 6ef74a58be6ee453452470f274a76b5fc5fa211b

Zoglun (talkcontribs)

Got this error in our wikis.

Is there any temporary fix for this bug?

AhmadF.Cheema (talkcontribs)

In case you are using the REL1_28 branch, run the following command, through SSH in the extensions/Lockdown directory:

git checkout b19a0a60a476ddbf5344395b339e928729c11f54

Zoglun (talkcontribs)

Cool, work immediately. Thank you!

Reply to "Bug (Special:Search)"

Letting anons create a page with Page Forms (MW 1.28.1, PF 4.1)

Cavila (talkcontribs)

I'm experimenting with a wiki that is mostly "locked down" except for one namespace, where anonymous users should be allowed to create new pages using a form. These users can edit and create pages with action=edit, they can edit an existing page using Page Forms - so far so good, but what they cannot do is create a new page using Page Forms. This is despite the fact that editing the namespace is enabled for anonymous users (*) as is the FormEdit special page.

You do not have permission to edit this page, for the following reason:

The action you have requested is limited to users in the group: Users.

What settings should be used to achieve this?

Reply to "Letting anons create a page with Page Forms (MW 1.28.1, PF 4.1)"
Nupur.patel (talkcontribs)

Hello having mediawiki 1.28 installed. Looked for various extentions to enable page restriction(edit / new / view) for groups but couldn't find it. Please do let us know if there is any possiblities for this.

Reply to "Page restriction in mediawiki1.28"