Extension talk:Lockdown

Jump to: navigation, search

About this board


Archives
Archive 1


By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
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

3
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"
Kghbln (talkcontribs)

-- Originally posted by 79.104.211.130 --

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:

action:parse

format:json

formatversion:2

title:<Title here>

text:<Content here>

pst:

prop:text|modules|jsconfigvars

preview:true

disableeditsection:true

uselang:ru

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

194.158.204.247 (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.

Reply to "Not working in MW 1.27 via API"
JamesPoulson (talkcontribs)

I installed Lockdown to restrict access to Special:ListUsers.

Added:

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

Added:

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

https://phabricator.wikimedia.org/T127456

https://phabricator.wikimedia.org/rELCK0d59ae7a7e0e3eb5a4638ba8f814a57926dada42

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"

Lockdown and VisualEditor - can't edit protected pages

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

https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid_in_private_wikis

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

Reply to "Lockdown and VisualEditor - can't edit protected pages"

Extension Lockdown blocks permission to SimpleBatchUpload

4
Innosflew (talkcontribs)

I installed the Lockdown extension to block acces for regular users to certain special pages. Everything works fine exept it blocks the uploading of files through the SimpleBatchUpload extension even though I didn't even configured the Lockdown extension to do that. How do I enable it for everyone to upload with the SimpleBatchUpload extension so I can use both extensions without any problems?

Kghbln (talkcontribs)

I believe that you ran into the issue described here. I'm afraid that until this is fixed you will not be able to use both extension side by side on the same wiki.

Innosflew (talkcontribs)

I see. Btw are you one of the developers of this extension? If yes do you know when we can expect a fix?

Kghbln (talkcontribs)

I am not the developer and myself eagerly waiting for a fix for some time now. Perhaps you could voice you problem on phabricator too. The more people indicate that they have an issue ...

Reply to "Extension Lockdown blocks permission to SimpleBatchUpload"

Permission denied error with MsUpload and Uploadwizard

3
Christharp (talkcontribs)

I assume this is connected to the problem with the API described below, but maybe not. Lockdown version 1.27 blocks any uploads with permission denied statements for both the Extension:MsUpload and Extension:UploadWizard. The normal upload function works fine.

@Kghbln -- Looks like I spoke too soon about the problems being solved with Lockdown 1.27

Kghbln (talkcontribs)

I guess we are talking about the same as in Not working in MW 1.27 via API. See also task T148582.

Kghbln (talkcontribs)

I guess we are talking about the same as in Not working in MW 1.27 via API. See also task T148582.

Reply to "Permission denied error with MsUpload and Uploadwizard"

Still not working in MW 1.27 for regular users

12
Summary by Kghbln

If you are working with MediaWiki 1.27.x make sure you are using REL1_27 of this extension. Versions of Lockdown which are meant to work with MW <= 1.26 and >= 1.28 will not work with 1.27

Christharp (talkcontribs)

Cloned it, downloaded it, etc., but still not working. AS far as I can tell I have the newest version. Any help would be great @Kghbln

Kghbln (talkcontribs)

Works for me. Are you sure that you are on REL1_27 of this extension? Indeed, master will not work.

Christharp (talkcontribs)

Tried and tried. Nothing seems to work. Tried downloading, tried git clone, etc., tried the REL1_27 and the master. It never works. So not sure what is going on if it's working for other people.

Kghbln (talkcontribs)

This is a bit confusing. You could try to manually apply the change. Apart from that: What exactly is not working for you?

Stefahn (talkcontribs)

I tried master too at first (which didn't work). Then I used the Extension Distributor, which gave me the working version :)

176.195.65.39 (talkcontribs)

I tried to use Lockdown within private wiki (i.e. $wgGroupPermissions['*']['read'] = false).

It breaks WikiEditor preview feature. I found that even being sysop I don't have read right for API. Digging further showed that 'user' (and 'autoconfirmed') implicit groups were not added to my user (thus leaving only explicit ones and '*'), while basic permissions such as read/write are in 'user' group. I am not that good with MW code to figure out the reason, but it appears that Lockdown calls User::GetRights() too early which results in memoizing only '*' group in mEffectiveGroups.

The version cloned from the git master would not allow me read rights at all, so I cannot access my wiki even as sysop.

Kghbln (talkcontribs)

I just tested with WikiEditor and I cannot confirm your observation. I think the issue is that you did not upgrade your version of Lockdown in the first case and later on you just upgraded to master which will fail too as expected. Move in the version for MediaWiki 1.27 i. e. REL1_27 since this is actually the only working version for MW 1.27.x.

79.104.211.130 (talkcontribs)

You are right, I reinstalled REL1_27 anew and the problem resolved.

Kghbln (talkcontribs)

Great, thanks for confirming.

79.104.211.130 (talkcontribs)

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:

action:parse

format:json

formatversion:2

title:<Title here>

text:<Content here>

pst:

prop:text|modules|jsconfigvars

preview:true

disableeditsection:true

uselang:ru

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:

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

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

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

# Enabled Extensions. Most extensions are enabled by including the base extension file here

# but check specific extension documentation for more details

# The following extensions were automatically enabled:

wfLoadExtension( "Cite" );

wfLoadExtension( "Interwiki" );

wfLoadExtension( "SyntaxHighlight_GeSHi" );

wfLoadExtension( "WikiEditor" );

wfLoadExtension( "ParserFunctions" );

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

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

$wgScribuntoDefaultEngine = 'luasandbox';

# File upload

$wgFileExtensions[] = 'docx';

$wgFileExtensions[] = 'doc';

$wgFileExtensions[] = 'xlsx';

$wgFileExtensions[] = 'xls';

$wgFileExtensions[] = 'pptx';

$wgFileExtensions[] = 'ppt';

$wgFileExtensions[] = 'pdf';

$wgFileExtensions[] = 'mpp';

$wgFileExtensions[] = 'odt';

$wgFileExtensions[] = 'ods';

$wgFileExtensions[] = 'odg';

$wgFileExtensions[] = 'odp';

$wgFileExtensions[] = 'djvu';

$wgFileExtensions[] = 'svg';

# Hide Powered icon

$wgFooterIcons = ['copyright' => ['copyright' => false]];

# Hide About/Privacy etc footer links

$wgHooks['SkinTemplateOutputPageBeforeExec'][] = 'hookFooterLinks';

function hookFooterLinks( $sk, &$tpl ) {

$tpl->data['footerlinks']['places'] = array();

return true;

}

## WikiEditor

# Enables use of WikiEditor by default but still allows users to disable it in preferences

$wgDefaultUserOptions['usebetatoolbar'] = 1;

# Enables link and table wizards by default but still allows users to disable them in preferences

$wgDefaultUserOptions['usebetatoolbar-cgd'] = 1;

# Displays the Preview and Changes tabs

$wgDefaultUserOptions['wikieditor-preview'] = 1;

# Displays the Publish and Cancel buttons on the top right side

$wgDefaultUserOptions['wikieditor-publish'] = 1;

define("NS_RD", 3000);

define("NS_RD_TALK", 3001);

define("NS_TO", 3002);

define("NS_TO_TALK", 3003);

define("NS_CERT", 3004);

define("NS_CERT_TALK", 3005);

$wgExtraNamespaces[NS_RD] = "РД";

$wgExtraNamespaces[NS_RD_TALK] = "РД_Обсуждение";

$wgExtraNamespaces[NS_TO] = "ТО";

$wgExtraNamespaces[NS_TO_TALK] = "ТО_Обсуждение";

$wgExtraNamespaces[NS_CERT] = "С";

$wgExtraNamespaces[NS_CERT_TALK] = "С_Обсуждение";

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

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

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

$wgNamespacePermissionLockdown[NS_RD]['edit'] = array('sysop', 'rd');

$wgNamespacePermissionLockdown[NS_TO]['edit'] = array('sysop', 'to');

$wgNamespacePermissionLockdown[NS_CERT]['edit'] = array('sysop', 'cert');

Hope this will help.

Rrosenfeld (talkcontribs)

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)

To prevent this thread from getting messy all the way I created a separate one called " Not working in MW 1.27 via API"

Strange behavior with MW1.27

11
Summary by Kghbln

Fixed in the repo. Either clone latest REL_27 code or download the software from the extension distributor for the MW 1.27 branch. // Earlier versions of this exension's code will not work with MW 1.27+

5.29.75.205 (talkcontribs)

I recently updated MW to the latest commits (it was 1.27 from late 2015). Since than Lockdown is causing very strage permission behavior, apparently it does not recognize the different between logged users and anonymous users (i.e - logged-on sysop cannot edit MW namespace pages, logged users cannot edit etc.

Wess (talkcontribs)

Facing the same situation. Maybe there's a change in recent commits regarding user permissions?

Kghbln (talkcontribs)

I suspect that this is what I described in task T137051. To sum up: Lockdown is not compatible with MW 1.27 yet.

Aloist (talkcontribs)

Did the fix Lockdown: 0d59ae7a7e0e3eb5a4638ba8f814a57926dada42 work?

Kghbln (talkcontribs)

No, unfortunately not.

Aloist (talkcontribs)

Is somebody going to fix it?

At the moment, when I want to mange user rights, I had to disable the Lockdown extension.

I need it however to protect some namespaces from public access,

Kghbln (talkcontribs)

Hopefully. I am not a coder so I cannot do it. Keeping fingers crossed.

Aloist (talkcontribs)

I think I have a fix.

Using the version from git master, file Lockdown.php dated 31-may-2016, I replaced

in function function lockdownSearchableNamespaces($arr) {

the line

//if ( $user->getId() === null && $user->getName() === null ) {

with

if ( $user->getId() === null || $user->getName() === null || $user->getName() == '' ) {

I do not claim to understand it, but it resolves the problem that the extension locks out users from editing, who normally have the permission to edit.

108.171.128.176 (talkcontribs)

im still seeing the problem that i cant add or edit permissions for users as a sysop, even after applying the change above :/

Kghbln (talkcontribs)

I have uploaded a patch set suggested by a user which at least restores functionality: gerrit. I dunno if it gets through though. The current status on this issue is however always visible on phabricator.

Kghbln (talkcontribs)

REL1_27 has now been fixed with a patch from Javawookie. Thanks a lot.

Restrict createpage-right in Project-Namespace

4
Finswimmer (talkcontribs)

Hello, what's the right way to restrict the right to create a page in the Project-namespace (NS_PROJECT) to a certain group, but allow all other to edit them.

I tried this:

$wgGroupPermissions['*']['edit'] = true;
$wgNamespacePermissionLockdown[NS_PROJECT]['createpage'] = array('sysop');

But it wont work. Still every logged in user can create pages in the project namespace.

76.68.137.45 (talkcontribs)

Did you ever get this to work?

Kghbln (talkcontribs)

Hmm... , I do not think this can be done since action "edit" includes action "createpage" (some sort of "rights inheritance"). However, I may still be proven wrong.

Rbirmann (talkcontribs)

I am trying to do something similar and indeed it does not seem to work. I want only members of a certain group to be able to create pages on the main namespace, but allow everyone else to edit those pages once they exist.

Here is what I tried:

$wgGroupPermissions['user']['createpage'] = true;
$wgGroupPermissions['creator']['createpage'] = true;
$wgNamespacePermissionLockdown['*']['createpage'] = array('user');
$wgNamespacePermissionLockdown[NS_MAIN]['createpage'] = array('creator');

But it does not work. All users can still create pages on the Main Namespace, even if they are not members of the 'creator' group.

Too bad....

Reply to "Restrict createpage-right in Project-Namespace"