Extension talk:Lockdown

Jump to: navigation, search

About this board

Archive 1

Calion (talkcontribs)

I don't think you create user groups by adding them to Manual:$wgGroupPermissions (at Extension:Lockdown#Managing groups).

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)

This is really a greate extension!

Is there a possibility to lockdown the side that is shown after the "compare selected revision" at the "revision side" like shown on https://www.mediawiki.org/w/index.php?title=Extension%3AMsCatSelect&type=revision&diff=2520718&oldid=2520717

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)

I replaced the ApiParse.php file with the newest code from: https://raw.githubusercontent.com/wikimedia/mediawiki/master/includes/api/ApiParse.php

And it does not work too.

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)

There seems to be progress on this front. A backport of https://gerrit.wikimedia.org/r/#/c/303369/ will hopefully fix the issues on REL1_27 once and for all. Keeping fingers crossed.

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"
The Patriot Woodworker (talkcontribs)

Curious, I am trying to disable Extension:Lockdown, but it is not in my LocalSettings.php as an enabled extension. Yet is does show as invoked at Special:Version.

Where else would this extension be so I can disable it?

Thanks for any help!

Kghbln (talkcontribs)

I think to remember that you are using BlueSpice. If this is the case when have a look at the "LocalSettings.BlueSpiceDistribution.php" file which is one of the four additional settings files this suite is using and comment it out there.

The Patriot Woodworker (talkcontribs)

Karsten thanks sir. I apologize for not mentioning that, from here on out I need to disclose that important fact about BlueSpice usage on our wiki's.

Appreciate your help.

Kghbln (talkcontribs)

Others would not have been able to answer without knowing this. Yeah, it is always better to disclose important facts about your setup. Software bundles are one of these.

Reply to "Lockdown Invoked, But Not Found"

Can't restrict editing to registered users in MW 1.27

Entropy (talkcontribs)

I don't want guests to be able to edit any pages, but I want registered users to be able to. Here is my configuration:

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

This works fine until I install Lockdown. Once I do, nobody (including administrators) can edit anything. I get this error:

   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 gives? Entropy (talk) 23:45, 14 December 2016 (UTC)

Ryan.lewkowicz (talkcontribs)

I don't think it works with 1.27. I use the exact same options in 1.28 and it's fine, but then other crap breaks (not with lockdown, but with VE).

Cavila (talkcontribs)

This is a known issue - see the post below. But good to know that it should work with 1.28.

Reply to "Can't restrict editing to registered users in MW 1.27"
JamesPoulson (talkcontribs)

I installed Lockdown to restrict access to Special:ListUsers.


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


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

Then changed it to:

$wgSpecialPageLockdown['Listusers'] = array('user','sysop');

As a result I couldn't access Special:ListUsers as an admin and I couldn't edit any pages as they are restricted to users.

This is quite unexpected.

I'm going to have a re-read through the manual :p

Kghbln (talkcontribs)

Indeed this appears quite unexpected. The settings as such look ok to me so there is perhaps something else in the water. What are we versions of MediaWiki, Lockdown and PHP you are using? Perhaps it is a bug worth reporting.

Ryan.lewkowicz (talkcontribs)

I'm having the same issue (and really just a slew of weird issues that I can't quite pin down), using latest 1.27 from github. Lockdown from distribution for 1.27 and php7. I think it's related to this:



I think something in 1.27 broke the way users are handled. If you try to hit $wgUser in Localsettings.php with something like $wgUser->getName() you'll hit an exception somewhere in the chain since it can't access null. I ended up having to do certain things via OutputPageBeforeHTML so I knew for a fact the user was loaded.

I'm almost thinking about loading the extension on the usercan can hook and seeing if that will force a proper load order.

I'm not cool enough to understand the full scope of the application yet

Ryan.lewkowicz (talkcontribs)

To add, this https://github.com/rlewkowicz/docker-mediawiki-stack is an exect version of my install (minus Lockdown). Parsoid is a bit weird since I have to forward through nginx becuase it wants host to be the same in localsettings and parsoid settings and if it's in containers, that doesn't work. At somepoint I'll get rest base up and running

Kghbln (talkcontribs)

I cannot replicate this on MediaWiki 1.27.1 and Lockdown REL1_27. However I use PHP 5.6 for the change. Issue T127456 was indeed a pain but has been resolved. So this should not be the issue for you. T148528 is still open. Perhaps this is the one troubling you too.

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.

Reply to "Unable to edit pages as an admin"