Extension talk:Lockdown

Jump to: navigation, search

About this board

Edit description

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

Update

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

Reply to "Bug (Special:Search)"
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.

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

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

Reply to "Not working in MW 1.27 via API"

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

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

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"
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"