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"

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

Hide specific page except to owner?

1
MavropaliasG (talkcontribs)

Hi @Duesentrieb thank you for the great extension.

I wanted to ask you if Lockdown or another method would allow me to do the following.

  1. Someone creates a page. That page is automatically ONLY visible to the owner (hidden from anyone else) but the owner can also invite others to see the page.
  2. Only the owner (original creator) can edit the page, but they can allow others to edit it if they want.
  3. The owner can choose to publish the page (make it publicly visible)
  4. If they make they publish the page, the revision history of when it was private does not show, instead the revision history is reset and starts anew for the public version.

Please let me know, thank you.

Reply to "Hide specific page except to owner?"

Upgrade MW 1.34 - LockDown stops working

1
IMTS-TB (talkcontribs)

Hi there,


My first post here, so please be gentle!


Been working with, and administering, our private MediaWiki for close to a year now.

Set it up, including LockDown, starting with version 1.31.x (if I remember correctly).

LockDown of our custom NameSpaces has worked fine, no issues. I set it up so that a usergroup has edit/create rights within their own NameSpace, and only Read rights in all other custom NameSpaces.

Now, after upgrading MediaWiki to 1.34.0, when browsing to a page within another NameSpace, I receive an error on that page (translated from Dutch):


This page does not function

wiki.domain,name can not process this request.

HTTP ERROR 500


If I disable the extionsion LockDown in the LocalSettings.php, all pages are viewable (and editable).

Does anybody else have this problem, or a way to resolve this issue?


One of the sections from our LocalSettings.php:

wfLoadExtension( 'Lockdown' );

# Start with assigning the default permissions from group "autoconfirmed"

$wgGroupPermissions['IMTSSB_Users'] = $wgGroupPermissions['autoconfirmed'];

# Add the permissions from group "bot"

$wgGroupPermissions['IMTSSB_Users'] = array_merge($wgGroupPermissions['IMTSSB_Users'], $wgGroupPermissions['bot']);

# Now modify these rights:

$wgGroupPermissions['IMTSSB_Users']['delete'] = true;

$wgGroupPermissions['IMTSSB_Users']['protect'] = true;

$wgGroupPermissions['IMTSSB_Users']['patrol'] = true;


## Custom Namespaces

# Create Custom Namespaces

define('NS_IMTSSB', 500);

define('NS_IMTSSB_TALK', 501);

define('NS_IMTSNB', 502);

define('NS_IMTSNB_TALK', 503);

define('NS_IMTSAB', 504);


# Define Custom Namespaces

# Custom Namespace "IMTSSB" Serverbeheer

$wgExtraNamespaces[NS_IMTSSB] = 'IMTSSB';

$wgExtraNamespaces[NS_IMTSSB_TALK] = 'IMTSSB_talk';

# restrict "read" permission to anyone

$wgNamespacePermissionLockdown[NS_IMTSSB]['read'] = [ '*' ];

$wgNamespacePermissionLockdown[NS_IMTSSB_TALK]['read'] = [ '*' ];

# give all permissions to members of IMTSSB_Users group

$wgNamespacePermissionLockdown[NS_IMTSSB]['*'] = [ 'IMTSSB_Users' ];

$wgNamespacePermissionLockdown[NS_IMTSSB_TALK]['*'] = [ 'IMTSSB_Users' ];

# prevent inclusion of pages from that namespace

$wgNonincludableNamespaces[] = NS_IMTSSB;

$wgNonincludableNamespaces[] = NS_IMTSSB_TALK;

Reply to "Upgrade MW 1.34 - LockDown stops working"

Not working in MW 1.27 via API

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

Loman87 (talkcontribs)

Hi, any news about this issue? Is there any chance to solve it if I upgrade to 1.28?

Thanks,

Lorenzo

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!

Bye,

Lorenzo

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

Scrap host (talkcontribs)

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

For Anonymous users access for api denied. It makes problem for MultimediaViewer extension for this users.


To solve this problem you can use (in LocalSettings.php):

$wgMediaViewerUseThumbnailGuessing = true;

(maybe $wgMediaViewerIsInBeta = true; needed.)


Reply to "Not working in MW 1.27 via API"

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"

createpage only permissions?

2
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"
Return to "Lockdown" page.