Does not work on 1.16, over riding permissions

Simply does not work on 1.16 end of debate.

I use the version for 1.15 in 1.16, works fine so far. —The preceding unsigned comment was added by an unknown user on a unknown date. 04:49, 6 June 2011 (UTC)

Extension doesn't work with 1.16.0

The extension doesn't work! If i enable Lockdown, I'm able to edit group membership of every user, while not logged in! I can see every special page, also those, usually only visible to sysops! I'm not using any Lockdown-feature. I only enable it in Localsettings with the line require_once("$IP/extensions/Lockdown/Lockdown.php") and all permissions defined anywhere are deactivated. If Lockdown is enabled, lines like $wgGroupPermissions['*']['edit'] = false; are completely ignored, no matter if the line is placed before or after the Lockdown-line.
Is this normal behaviour? I'm using MediaWiki 1.16.0. The lines in my LocalSettings.php are:

# Lockdown
require_once( "$IP/extensions/Lockdown/Lockdown.php" );
# Force login to edit
$wgGroupPermissions['*']['edit'] = false;

You don't have to use the extension, it's to enough to simply enable it!
Any idea? --82.135.46.2 10:46, 12 January 2011 (UTC) 04:50, 6 June 2011 (UTC)

Update:

Now the extension works after doing this:

1. Create a restricted namespace
2. Create an article in that namespace with a user who has permission to do that
3. Log-out (until now, nothing had changed; I'm still able to access sysop special pages and change user rights as an anonymous)
4. Search for the article, created in step two
5. Click on the result (there shouldn't be a result!)
6. Now you get a restriction failure
7. From now on, the extension works as expected

The buggy behaviour, described above appeared today's morning out of nowhere. I used the extension for several weeks and saw it today for the first time. Any idea about that? --82.135.46.2 11:57, 12 January 2011 (UTC) 04:50, 6 June 2011 (UTC)

Update:

Now I have figured out the problem: It's something with the cookies. You can reproduce it in the following way:

1. Log in to your wiki as an admin
2. Close your browser
3. Open your browser
4. Check your cookies: there are two left: wikinameUserID and wikinameUserName
5. Navigate to your wiki
6. Go to Special Pages
7. Here you can see all pages, you could see as an admin, even though you're not logged in!
8. Deactivate the Lockdown Extension at LocalSettings.php
9. Reload Special Pages
10. Now, everything's OK; you're treated as an anonymous, without any rights
11. Reactivate the Lockdown Extension at LocalSettings.php
12. Reload Special Pages
13. Now you're treated as an admin
14. Delete one of that cookies mentioned above, it doesn't matter which one
15. Now you're treated as an anonymous

You see: The Lockdown-Extension is the problem.
--82.135.46.2 09:55, 14 January 2011 (UTC) 04:51, 6 June 2011 (UTC)

There was a full thread on this showing how to reproduce exactly the same issue you're seeing but by deleting the PHP session on the server itself... apparently it wasn't migrated over when the discussion was switched from a one-page flat format.

I tried to work extensively to get it brought to someone's attention. Admins here seem more interested in telling users they're wrong and don't know how to use the extension rather than investigating the issue and trying to figure out where it's coming from for some people. RandomUser42 15:29, 10 August 2011 (UTC)

Here's the post from the previous discussion copied over -

Reproduce buggy behavior

Log into the wiki and leave the browser open and wait for your session to expire. (I've read this may be influenced by session.gc_maxlifetime and session.cache_expire in php.ini, but this doesn't seem to be the case for me.) After it expires, you should be able to edit the pages without being logged in.

Update: Here's a much quicker way to make your php session end, and to be able to see the bug. Find where your php sessions are being stored (this is session.save_path in phpinfo(), default /var/lib/php5/ on Ubuntu). Grep the files for your logged in username. Delete the session file for your session. Apache/PHP will recreate it as soon as you navigate to another page on your wiki - however, you should now be logged out AND able to edit pages without logging in. I'm beginning to wonder if this is more of a Mediawiki bug than a bug with this extension 15:35, 10 August 2011 (UTC)

No Problem  :)

Hi. I updated my wiki last week from 1.15.3 to 1.16.1 . I used Lockdown and it continues to work fine. No see this kind of problem and no member reports me anything wrong. Must be a very restricted bug ?? —The preceding unsigned comment was added by an unknown user on a unknown date. 04:51, 6 June 2011 (UTC)

2 Small bugs, Recording user name to history and group name with a space character

Ran into a small bug. Mediawiki 1.16.1 installed. Run Lockdown to restrict pages to the "read only" on a Namespace to all users. Sysop has full permissions to this namespace and I created another group name designated to allow edit, create, and move access on the namespace.

Both are minor.

1st was a user group name, "Namespace editor" and the fact it was not being recognized at all. Yes, I had created the group name and it was in the choices of user rights management page. However, the choice would not hold, nor would it record the choice to give a user that group right. Solved it by naming the group... "NamespaceEditor" as one word no space and it took just fine.

2nd was upon granting the right to an existing user the additional permissions of "NamespaceEditor" there was problem recording to the history of the page upon the edit. It recorded the IP of the user and not his user name. My wiki only allows those with a user account to create, edit, etc. He was already logged in, so it may have been the system recognized he had a new permission, the ability to now edit the Namespace, but was unable to resolve his user name to the history of the page. At first I thought it was a cookie issue, because he stated he was thrown out of log in after he made the edit. However, he made three edits, all on different pages in the Namespace, and it was the 3rd edit upon saving he was thrown out of log in.

He has since logged out, cleared his browser's cache, then logged in again. It is now recording his user name to the Namespace page edits. I am now trying to recreate the bug and will advise if I can. Any one else run into this? Hutchy68 04:52, 6 June 2011 (UTC)

Hutchy68, was your user still able to edit (and have his IP show up in the history) after having been logged out? That's the issue quite a few of us are seeing in 1.16. --134.161.2.55 14:20, 25 January 2011 (UTC) 04:52, 6 June 2011 (UTC)

Why is there a "Warning" for 1.16 on the main page?

Shouldn't the warning be modified to read "Possibly broken for 1.16 if client-side caching is enabled and users don't read the instructions"?

It seems like almost all the issues that people are having are client-side caching or RTFM failures.

I use a combination of Lockdown for Action and Special Page lockdowns, and Extension:SimpleSecurity for namespace management. I have found this to be a rock-solid combination for my relatively simple needs since 1.14 and through 1.16.1, including a public-facing CMS as well as completely private extranet sites with multiple (albeit relatively simple) permission needs.

For those with the freedom to hack and patch their source code and the time to configure things (and work out all sorts of possible Javascript, skin, database, and administration issues), Halo Access Control List may be a possible option, but I have yet to be able to get it to work in a way that meets my needs. --Fungiblename 07:42, 31 January 2011 (UTC) 04:53, 6 June 2011 (UTC)

Browser Issue

Hi When I use this extension along with Mediawiki 1.16.1 and these are the options wth which I use the lockdown extension

• $wgActionLockdown['history'] = array('user');
• $wgActionLockdown['edit'] = array('user');
• $wgNamespacePermissionLockdown[SF_NS_FORM]['read'] = array('user');
• $wgSpecialPageLockdown['CreateForm'] = array('user');
• $wgSpecialPageLockdown['AllPages'] = array('user');
• $wgSpecialPageLockdown['ListUsers'] = array('user');
• $wgSpecialPageLockdown['BlockList'] = array('user');
• $wgSpecialPageLockdown['Log'] = array('user');
• $wgSpecialPageLockdown['RecentChanges'] = array('user');
• $wgSpecialPageLockdown['Version'] = array('user');
• $wgSpecialPageLockdown['CreateCategory'] = array('user');
• $wgSpecialPageLockdown['CreateProperty'] = array('user');
• $wgSpecialPageLockdown['CreateTemplate'] = array('user');
• $wgSpecialPageLockdown['Ask'] = array('user');
• $wgSpecialPageLockdown['FormStart'] = array('user');
• $wgSpecialPageLockdown['FormStart'] = array('user');

These seem to be working perfectly as expected with Firefox browser(3.6.15) but when I use crome(9.0.597.94) none of the things seem to work.Can you please help me? —The preceding unsigned comment was added by an unknown user on a unknown date. 04:54, 6 June 2011 (UTC)

Security Flaw

If a user creates a redirect to a protected page while using the Vector skin, the user can access that page regardless of whether they have read access or not. Ecliptica 21:32, 6 April 2011 (UTC) 04:54, 6 June 2011 (UTC)

This also applies to inclusion {{:Page}} of redirects #REDIRECT:[[Protected:Page]]. TiCPU 13:30, 3 August 2011 (UTC) 13:30, 3 August 2011 (UTC)

For myself I fixed it using:

diff -udpr includes//parser/Parser.php /root/mediawiki/mediawiki-1.16.4/includes/parser/Parser.php
--- includes//parser/Parser.php	2011-08-03 09:43:32.000000000 -0400
+++ /root/mediawiki/mediawiki-1.16.4/includes/parser/Parser.php	2010-05-11 22:12:12.000000000 -0400
@@ -3154,7 +3154,7 @@ class Parser
 		$deps = array();
 
 		// Loop to fetch the article, with up to 1 redirect
-		for ( $i = 0; $i < 1 && is_object( $title ); $i++ ) {
+		for ( $i = 0; $i < 2 && is_object( $title ); $i++ ) {
 			# Give extensions a chance to select the revision instead
 			$id = false; // Assume current
 			wfRunHooks( 'BeforeParserFetchTemplateAndtitle', array( $parser, &$title, &$skip, &$id ) );

Almost the same as removing the loop, Mediawiki won't fetch redirect in inclusion now. TiCPU 13:49, 3 August 2011 (UTC)

My configuration is MW 1.17 with LdapAuthentication 1.2d.

I have restricted access to a page by moving it in a NS_protected namespace.

My lockdown configuration is : $wgNamespacePermissionLockdown[NS_protected]['read'] = array('mygroup');

This work fine but not with page inclusion {{:NS_protected:Page}} or redirection #REDIRECT:[[NS_protected:Page]].

I have tried to patch Parser.php like TiCPU but still have the problem. Klausla 09:17, 8 September 2011 (UTC)

Problems with MediaWiki 1.16.5

I've installed a new MediaWiki sing 1.16.5, where anonymous users do not have the right to edit pages. When I enabled the Lockdown extension, without any further Lockdown config, the edit tab is removed for all logged in users.

Tracing the code the lockdownUserCan() is only called for the read action for logged in users and no further and then lockdownSearchableNamespaces() is called twice when loading a page. Disabling the lockdownSearchableNamespaces() hook makes the problem go away so I investigated further down this way. It turns out that changing

$ugroups = $wgUser->getEffectiveGroups();

inside lockdownSearchableNamespaces to

$ugroups = $wgUser->getEffectiveGroups(true);

fixes this (this disables the cache for getEffectiveGroups()).

With this change my MediaWiki installation works and now lockdownUserCan() is called in addition for edit and move actions when loading a page (after the two calls to lockdownSearchableNamespaces()).

I'm very new to MediaWiki, let alone the MediaWiki APIs, so I'm not sure if this is the correct fix or not or what is actually going on.

For reference the relevant permission related parts of LocalSettings.php are:

$wgGroupPermissions['*']['createaccount']    = false;
$wgGroupPermissions['*']['edit']             = false;
$wgGroupPermissions['*']['createpage']       = false; # 'createpage' requires the 'edit' right
$wgGroupPermissions['*']['createtalk']       = false; # 'createtalk' requires the 'edit' right
$wgGroupPermissions['*']['writeapi']         = false;

# despite documented defaults administrators do not have 'suppressredirect' by default
$wgGroupPermissions['sysop']['suppressredirect'] = true;

require_once( "$IP/extensions/Lockdown/Lockdown.php" ); 212.147.27.179 14:01, 12 May 2011 (UTC) 04:55, 6 June 2011 (UTC)

This has already been fixed if you download the latest snapshot (the "trunk" version) of Lockdown. --Skizzerz 23:19, 12 May 2011 (UTC) 04:55, 6 June 2011 (UTC)

Nice! Great to see it fixed in a proper way ;-) Any chance the fix is propagated to the MW-1.16 snapshot? --212.147.27.179 09:49, 13 May 2011 (UTC) 04:55, 6 June 2011 (UTC)

Hi. Be careful here: if you install the "trunk" version of Lockdown you will need the "trunk" version of MediaWiki too!

I just tried it an got this error:

"Call to undefined method MediaWiki::getAction()"

Better to only correct these getEffectiveGroups() and wait next release of Lockdown, I think. 180.183.208.155 09:51, 14 June 2011 (UTC)

Since no one replied to my posting about 1.17 issues above, I decided to just try upgrading from 16.0 to 16.5 for the security fixes...this is the result.

Warning: Cannot modify header information - headers already sent by (output started
at ..../w/extensions/Lockdown/Lockdown.php:1) in ..../w/includes/WebResponse.php on line 16o

Is this extension being overseen any more? Thanks Hutchy68 13:52, 31 January 2012 (UTC)

Lockdown not showing user groups

I have some strange behavior with lockdown (1.16-r70092) using MW 1.16.5. When I write 'require_once("$IP/extensions/Lockdown/Lockdown.php");' to my LocalSettings.php the Special:Preferences page won't show my user groups anymore (even though they are displayed in the groups List (Special:ListUsers&group=bureaucrat)). I would not mind that, but it also deletes my userrights-permission (i.e. no access to Special:UserRights), so I can't setup the Lockdown Extension properly. Is there any way to work around that? --141.20.192.102 12:02, 3 June 2011 (UTC) 04:56, 6 June 2011 (UTC)

Hi, I also had that problem and I solved it by following the same instructions as below.

I simply changed all getEffectiveGroups() to getEffectiveGroups(true).

Hope this helps, Toniher 14:53, 9 June 2011 (UTC) 14:53, 9 June 2011 (UTC)

It does :) Thank you! 141.20.192.66 10:47, 10 June 2011 (UTC)

The complete patch to apply to the version of Lockdown from 1_17_0 svn-tree:

--- svn-extensions/Lockdown/Lockdown.php        2011-06-27 19:53:38.000000000 +0000
+++ man-extensions/Lockdown-patched/Lockdown.php        2011-06-27 20:26:20.000000000 +0000
@@ -96,7 +96,7 @@
        # print "<br />nsAccessUserCan(".$title->getPrefixedDBkey().", ".$user->getName().", $action)<br />\n";
        # print_r($groups);
 
-       $ugroups = $user->getEffectiveGroups();
+       $ugroups = $user->getEffectiveGroups(true);
        # print_r($ugroups);
 
        $match = array_intersect( $ugroups, $groups );
@@ -127,7 +127,7 @@
        if ( $groups === null ) return true;
        if ( count( $groups ) == 0 ) return false;
 
-       $ugroups = $user->getEffectiveGroups();
+       $ugroups = $user->getEffectiveGroups(true);
        $match = array_intersect( $ugroups, $groups );
 
        if ( $match ) return true;
@@ -136,7 +136,7 @@
 
 function lockdownSearchableNamespaces($arr) {
        global $wgUser, $wgNamespacePermissionLockdown;
-       $ugroups = $wgUser->getEffectiveGroups();
+       $ugroups = $wgUser->getEffectiveGroups(true);
 
        foreach ( $arr as $ns => $name ) {
                $groups = @$wgNamespacePermissionLockdown[$ns]['read'];
@@ -155,7 +155,7 @@
 function lockdownTitle(&$title) {
        if ( is_object($title) ) {
                global $wgUser, $wgNamespacePermissionLockdown;
-               $ugroups = $wgUser->getEffectiveGroups();
+               $ugroups = $wgUser->getEffectiveGroups(true);
 
                $groups = @$wgNamespacePermissionLockdown[$title->getNamespace()]['read'];
                if ( $groups === NULL ) $groups = @$wgNamespacePermissionLockdown['*']['read'];
@@ -184,7 +184,7 @@
                return true;
        }
 
-       $ugroups = $wgUser->getEffectiveGroups();
+       $ugroups = $wgUser->getEffectiveGroups(true);
 
        foreach ( $searchEngine->namespaces as $key => $ns ) {
                $groups = @$wgNamespacePermissionLockdown[$ns]['read'];

91.61.104.241 20:47, 27 June 2011 (UTC)

This patch was added with r94275 Cheers [[kgh]] 21:29, 7 December 2011 (UTC)

Works on 1.17 as well, thanks for your effort 194.213.2.40 15:02, 12 July 2011 (UTC)

It only works correctly with 1.17 in the case you have run the update.php after having replaced the corrected lockdown.php. Feechen 21:41, 5 August 2011 (UTC)

Cannot edit protected pages with Bot in LockDown wiki

Hello,

I have noticed that I cannot edit pages with Perl MediaWiki::Bot bots if they are protected ('protect' or 'autoconfirmed' protections). No problem when done using the same bot logged in as user from the browser. The error I get in the script: Error code 3: protectedpage: The ``autoconfirmed right is required to edit this page at myscript.pl line 189. Any idea? Toniher 20:18, 10 July 2011 (UTC)

Apologies, it's also failing with Lockdown disabled. So it must be another thing. Toniher 10:54, 11 July 2011 (UTC)

No, it still fails. Apart from the previous error, it does not get the bot flag: Mybot doesn't have a bot flag; edits will be visible in RecentChanges at /usr/local/share/perl/5.10.1/MediaWiki/Bot.pm line 1928.. No problem when logged from the browser, though. I'll continue researching. Toniher 07:03, 12 July 2011 (UTC)

The problem I comment is with hook SearchableNamespaces, once only this is disabled, bot is loaded with proper permissions. I suspect it must be MediaWiki bug therefore. I filled a bug. Unless you host private content, you can comment line: $wgHooks['SearchableNamespaces'][] = 'lockdownSearchableNamespaces'; to bring robots back to work. Toniher 15:50, 8 August 2011 (UTC)

permission error on Special:UserRights

Hello and exuse my english. Just installed Lockdown on MediaWiki 1.17.0. When entering as a bureaucrat who has 'userrights' privilege by default, there is a permission error on Special:UserRights, which claims i don't have such right to manage user rights. What could be the problem? Begging your pardon again. 81.30.184.63 17:56, 10 August 2011 (UTC)

Hi, I got the same problem myself. Try to apply getEffectiveGroups(true) patch you can see in another thread below. Otherwise, try to add this line:

$wgSpecialPageLockdown['Userrights'] = array('sysop', 'bureaucrat');

Hope this helps! Toniher 10:43, 11 August 2011 (UTC)

After adding the line you advised, it works well. Thank you very much. 94.41.25.51 11:45, 11 August 2011 (UTC)

I had the same issue; adding the $wgSpecialPageLockdown line to LocalSettings.php, together with the getEffectiveGroups() hack described below, also fixed it for me. Dvd3141 06:48, 23 August 2011 (UTC)

possible conflict with ConfirmAccount extension?

Hi again, i using MediaWiki 1.17.0 and have installed both Lockdown and ConfirmAccount extensions. Without ConfirmAccount included in LocalSettings.php, Lockdown works excellent, and vice versa. But if included along, they does a common error, when registered user groups ('user', 'sysop' etc.) have rights as ' * ' group, not more. I have changed getEffectiveGroups() to getEffectiveGroups(true), like it was recommended below, but it didn't help. Can you please help me? 94.41.25.51 15:56, 11 August 2011 (UTC)

Problem with mw 1.17

I have used Lockdown with mw 1.15 and 1.16 with no problems. I upgraded a 1.15 to 1.17 with the correct extension version. Editing is configured to logged in users. Logged in as sysop I could not edit at all. Removing lockdown and leaving all other extensions all was fine. I set up a clean mw 1.17. Just added require Lockdown extension and sysop has no ability to see extra special pages. This is similar to comments below. Adding the patch below allows sysop to see the extra pages - 'User rights management'. However until the line $wgSpecialPageLockdown['Userrights'] = array('sysop', 'bureaucrat'); is added it is still impossible to use that page and set rights it says you do not have the right. Following that it now seems to work as expected. New namespaces can be locked to sysop and project can be locked to sysop.

There really does seem to be a fundamental problem with this extension and mw 1.17. This is a lot to work out for a simple install. Some indication should go in the main Lockdown extension page and hopefully an updated download for mw 1.17 produced. 86.163.48.222 12:08, 26 August 2011 (UTC)

The problem seems quite simple:

• MediaWiki starts loading the logged in user
• While loading it tries to get a list of searchable namespaces and calls the SearchableNamespaces-hook
• Lockdown kicks in and tries to calculate the searchable namespaces, but needs the groups for that
• Lockdown asks the user-object for the groups
• The user-object hasn't finished loading and hasn't loaded the groups yet, so it will only give '*' as the users' groups and caches that.
• Next time Lockdown - or anything at all! - asks for the groups it will get the cached version: '*'

Changing getEffectiveGroups() to getEffectiveGroups(true) tells MediaWiki to ignore the cache (and even repopulate it) and it will be fixed. However, the first time Lockdown asked for the groups it got a wrong answer so that could cause problems.

The solution is a unfortunately a lot less simple. I think the best way will be to let MediaWiki detect it hasn't loaded the groups yet and do that direct. (Or just change the order so the groups will be loaded before even thinking about searchable namespaces.)

Hope this helps. Quis 23:11, 3 September 2011 (UTC)

Here is what I am getting in my upgrade from Mediawiki 1.16 to 1.17.

<pre style="white-space: pre-wrap">Fatal error: Call to undefined method MediaWiki::getAction() in... ...extensions/Lockdown/Lockdown.php on line 130</pre>

Which throws back a 500 error. Any suggestions as I really need to upgrade another wiki using the Lockdown extension, but will not upgrade until I am sure Lockdown is working properly. Thanks Hutchy68 17:34, 24 January 2012 (UTC)

Edit--- Yes I am using version for 1.18 Hutchy68 17:34, 24 January 2012 (UTC)

I've the same issue. Have changed some php but locking of special pages also does not work... 213.197.11.102 11:10, 30 August 2012 (UTC)

whitelisted pages still need login when anonymous users read is set to false:

Hi.

This is my LocalSettings.php http://pastebin.com/Q39JFZX1

All pages listen in $wgWhitelistRead except Main_page and Hovedside(Main_page in norwegian) are then viewed. But the Main_page still needs logging in.

Im really not sure if I fucked something up, or if something is just broken.

The main_page contains links to all the other pages that can be viewed anonymously. So it's kinda vital that one can view it without logging inn. The other pages and the main page itself contains information on how to get access to the wiki, etc.. Also. Not everyone in the organization will/can have edit access to the wiki, but they will need the anonymous read access. JadeSoturi 17:31, 26 October 2011 (UTC)

I was just having this problem. I found out the issue was an underscore. Mediawiki is forgiving between "Main Page" and "Main_Page", but the script requires it be identical so you need to use "Main Page" and not "Main_Page". 128.61.16.249 19:25, 11 July 2012 (UTC)

why can't i get a non-trunk version for my mediawiki 1.17?

i have a mediawiki version 1.17 running but am unable to get a working version from the site. it say's unable to locate the svn-repository. help? 188.62.170.206 19:35, 7 November 2011 (UTC)

Lockdown and problems with common wiki handling

Hi,

when using Lockdown to keep an Namespace being hidden to normal users, we have the following problems:

User rights cannot be accessed, the listed patches on this side works very well for this!

BUT, pages cannot be deleted...wiki returns I don't have the rights, either if i'm sysop or bureaucrat

Additions to LocalSettings.php:

define("NS_ARKAN", 100);
$wgExtraNamespaces[NS_ARKAN] = "Arkan";
$wgGroupPermissions['arkanology']['Arkan_*'] = true;

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

$wgSpecialPageLockdown['Userrights'] = array('sysop', 'bureaucrat');
$wgNamespacePermissionLockdown[NS_ARKAN]['*'] = array('arkanology');


Sebastian 217.246.34.153 12:59, 14 November 2011 (UTC)

I have the same problem. I wnat only sysop to delete. I got round it with

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

$wgNamespacePermissionLockdown[NS_MAIN]['delete'] = array( 'sysop' );

Theory being set everyone to delete and then restrict the main namespace back to sysop. You may need to work through the namespaces if you want them restricted. To just bring back delete the first statement may be enough. 86.186.106.141 12:14, 26 November 2011 (UTC)

I have the same problem. I wnat only sysop to delete. I got round it with

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

$wgNamespacePermissionLockdown[NS_MAIN]['delete'] = array( 'sysop' );

Theory being set everyone to delete and then restrict the main namespace back to sysop. You may need to work through the namespaces if you want them restricted. To just bring back delete the first statement may be enough. 86.186.106.141 12:14, 26 November 2011 (UTC)

Locking down special pages

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? TheRebel 10:30, 20 November 2011 (UTC)

Thanks! A much better solution. People don't even know what they're missing. 203.118.164.219 00:16, 25 November 2011 (UTC)

This works perfectly. This should be linked to from restricting access pages. Thanks a bunch. 50.137.193.149 03:45, 23 July 2012 (UTC)

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';

Frantik (talk) 00:56, 30 March 2018 (UTC)

Thanks a lot for sharing! Much apprechiated! [[kgh]] (talk) 13:50, 3 April 2018 (UTC)

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!

AssetDenmark (talk) 08:32, 10 April 2019 (UTC)

Subscribe to RSS (Atom) feed

Is it possible to have a locked-down wiki that still allows me (as an administrator) to subscribe to the Recent Changes feed, to monitor updates? If so, how do I set this up? Dvd3141 03:08, 19 December 2011 (UTC)

Locdown on Special pages as a NS?

Hi I had a huge problem with nameSpaces and thus I an a bit reluctant to experiment. However what I want to do is a general lockdown on all special pages, less those to make a user login, and naturally a special namespace (say NS_Background). (Running 1.8.1)

Perhaps some of you have a suggestion or solution for me to do this?

I tried to lockdown everything, but the Background pages, like below. But I the anonymous user can't read the 'Background:' pages like this... so what did I miss?

$wgGroupPermissions['*' ]['edit']      = false;     
$wgGroupPermissions['*' ]['read']      = false;  
$wgNamespacePermissionLockdown[NS_Background]['read'] = array('*');
$wgNamespacePermissionLockdown[NS_Background]['edit'] = array('sysop');

What I really wanted to do is something like adding this, to the above:

$wgNamespacePermissionLockdown[NS_SPECIAL]['read'] = array('sysop'); ## Actually this may work??
$wgWhitelistRead = array ( < the special pages for search etc. > ); 

Alternately I would wish for at way to do something like this:

$wgWhitelistRead = array ("Background:", "Special:Search")  /  array ("Background:*", .....) 
$wgWhitelistEdit = array ("Discussion")  ## Giving permission to discus any readable page. 

So I guess I could use some kind of "function call" to build that area something like:

$myWhiteListedNameSpaces = getAllNameSpacesAsAnArray("NS_Background") ## or say getAllCategoryPagesAsAnArray("Background") 
$wgWhitelistRead = array ("Getting started", $myWhiteListedNameSpaces ) Asset 07:48, 15 February 2012 (UTC)

No download link

The download link is dead. 2001:6F8:1D1A:0:D03E:8EFE:DD5B:92B1 23:12, 2 July 2012 (UTC)

For me the links to the SVN server work correct. Rrosenfeld (talk) 08:49, 9 July 2012 (UTC)

Lockdown preventing users resetting their password

Hi.

If I have lockdown enabled then users are unable to reset their password or change their password if they have forgotten. They go through the process, but on the final step it says they do not have permission. If have the following defined:

$wgSpecialPageLockdown['ChangePassword'] = array('*');
$wgSpecialPageLockdown['PasswordReset'] = array('user');

But it still does not work. If I disable lockdown then password changes and resets work fine. What required permission am I missing?

Any ideas?

Thanks! Mitchelln (talk) 17:14, 29 November 2012 (UTC)

Works with 1.19.1

Hi all, thought I might just provide a small update. I've tested and implemented the following version details successfully:

MediaWiki 1.19.1 Lockdown-db7023e Quantos (talk) 15:13, 25 January 2013 (UTC)

Update Credits (for Special:Version)

This is picky and definitely not a priority, but it would be nice to be consistent with other extensions (plus, version ID's would be helpful for dependent developers such as myself).

For consistency, credits could be updated:

$wgExtensionCredits['other'][] = array(
	'path' => __FILE__,
	'name' => 'Lockdown',
	'author' => array( 'Daniel Kinzler', 'Platonides'),
	'url' => 'http://mediawiki.org/wiki/Extension:Lockdown',
	'version'  => "1.0",
	'descriptionmsg' => 'lockdown-desc',
);

jdpond (talk) 21:58, 16 March 2013 (UTC)

Making lockdown function

I have lockdown working fine using this:

$wgExtraNamespaces[100] = "Hide";
$wgExtraNamespaces[101] = "Hide_Talk";
$wgGroupPermissions['Hide'] = $wgGroupPermissions['user'];
$wgNamespacePermissionLockdown[100]['*'] = array('Hide');
$wgNamespacePermissionLockdown[101]['*'] = array('Hide');

I have to lockdown a BUNCH of namespaces and there are many admins on the site. So, I had the idea to write this function:

function make_lockdown_space($id, $name)
{
    global $wgExtraNamespaces, $wgGroupPermissions, $wgNamespacePermissionLockdown;
    $wgExtraNamespaces[$id] = $name;
    $wgExtraNamespaces[$id+1] = $name."_Talk";
    $wgGroupPermissions[$name] = $wgGroupPermissions['user'];
    $wgNamespacePermissionLockdown[$id]['*'] = array($name);
    $wgNamespacePermissionLockdown[$id+1]['*'] = array($name);
}

With this function, I theoretically only need:

make_lockdown_space(100, "Hide");

With that function, I check all the arrays. All are set. All look good. However, there is no lockdown. Anyone can see the namespaces that are supposedly locked down. Why? I don't see how it is possible that the arrays are altered without a problem, but lockdown fails. Anyone know what is happening? 71.204.230.66 22:44, 22 March 2013 (UTC)

block edit access to user page - except for admins?

block edit access to user page - except for admins?

$wgNamespacePermissionLockdown[user]['edit'] = array('syop');

Is this the correct coding? Using Mediawiki 1.16

It is not working.

Thank you Igottheconch (talk) 23:55, 5 April 2013 (UTC)

"Not absolutely sure but this seems more correct"

$wgNamespacePermissionLockdown[NS_USER]['edit'] = array('syop');

But yours might work also. Cheers, Mlpearc (powwow) 18:04, 28 July 2013 (UTC)

thank you sir,

I will try this! Igottheconch (talk) 06:00, 30 July 2013 (UTC)

Is it working for mw 1.19 ?

62.219.165.221 11:29, 28 July 2013 (UTC)

Is it working for mw 1.19 ?

Is it working for mw 1.19 ? 62.219.165.221 11:29, 28 July 2013 (UTC)

Locking everything down completely except reading the Main Namespace

I need some help.

I'd like to lockdown the wiki completely and operate as an internal private wiki, but have the main namespace readable by anyone.

That also means locking down access to view file history, special pages, etc..

Is Lockdown the way to do this.. if so how? And are there any security flaws? I know Mediawiki says it's not designed to be a CMS, but if the only thing outside users can do is read the main namespace, then where are the holes?

Thanks, MarkJurgens (talk) 01:53, 17 August 2013 (UTC)

update extension

hi please update this extension to support newer releases of mediawiki please. 86.135.253.19 12:01, 12 January 2014 (UTC)

Could you be more specific about this in case it is not working for MW 1.22? It will be nice to get a more verbose description of the issue which helps the programmers tackle it. Besides, adding the update template to the extensions page only means that the documentation should be updated. It is not read as a Call for Updating the extension itself. Cheers [[kgh]] (talk) 13:13, 12 January 2014 (UTC)

Not working in Mediawiki 1.21

Hello !

Your extension seems just perfect, but I can not make it work for Mediawiki 1.21. Am I missing something ? And I can not find previous versions of the extension.

I have set everything right but I can not manage to lock down rights (even following your exemples).

Thanks for your help ! 78.220.29.24 14:20, 21 January 2014 (UTC)

Working in MediaWiki 1.23wmf11

The trick it seems to get this extension to work is to ensure that your "$wgNamespacePermissionLockdown" config is beneath the 'require_once'.

Example:

#Enable Lockdown
require_once __DIR__ . "/extensions/Lockdown/Lockdown.php";
$wgNamespacePermissionLockdown[NS_TOPSCRT]['edit'] = array('FBI_Agents');
$wgNamespacePermissionLockdown[NS_TOPSCRT]['read'] = array('FBI_Agents');

Ckoerner (talk) 21:57, 6 February 2014 (UTC)

Yeah, the extension has to be invoked prior to using parameters defined by it. As far as I can see the installation and configuration instructions already say to do so but it might use a more explicit wording. I will now change it a bit. Cheers [[kgh]] (talk) 22:42, 6 February 2014 (UTC)

I have just submitted a patch to gerrit that changes this behaviour, so that you can also set the config variables before loading the extension. I think this may be simpler than changing the docs. Olenz (talk) 07:28, 7 February 2014 (UTC)

Well, this is one option too though the comments on the patchset are not in favour. Predominantly extension specific changes are made after the invokation. This also has the advantage that you quickly find the related settings in the "LocalSettings.php" file which is not the worst of ideas for inexperienced wikiadmins. [[kgh]] (talk) 15:44, 7 February 2014 (UTC)

Lockdown and VisualEditor - can't edit protected pages

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. Ckoerner (talk) 19:24, 19 February 2014 (UTC)

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! 47.19.118.253 19:51, 9 February 2015 (UTC)

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. 89.216.28.24 09:13, 18 March 2015 (UTC)

I have the same problem, but I use HaloACL extension.

Is there any chance to fix this? Monic abc (talk) 09:31, 27 March 2015 (UTC)

https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid_in_private_wikis Andrew Garrett (WMF) (talk) 11:27, 18 March 2015 (UTC)

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. 89.216.28.24 12:52, 18 March 2015 (UTC)

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? 163.244.62.183 (talk) 14:09, 15 July 2015 (UTC)

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 Gino3008 (talk) 14:48, 14 January 2016 (UTC)

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 HermannSchwärzler (talk) 11:36, 22 February 2016 (UTC)

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. Dieudo (talk) 01:00, 25 February 2016 (UTC)

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 HermannSchwärzler (talk) 09:51, 25 February 2016 (UTC)

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 (talk) 22:46, 25 February 2016 (UTC)

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 Dieudo (talk) 09:09, 26 February 2016 (UTC)

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;

}

HermannSchwärzler (talk) 15:38, 26 February 2016 (UTC)

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 ? Dieudo (talk) 22:48, 26 February 2016 (UTC)

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;

} Textform (talk) 08:26, 3 June 2016 (UTC)

Hi i have the same Problem here.

Where do you put the if Arguments? In the LocalSettings.php? 217.6.132.212 (talk) 15:34, 18 November 2016 (UTC)

Yes, "LocalSetting.php" [[kgh]] (talk) 12:33, 20 November 2016 (UTC)

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 109.199.10.165 (talk) 14:15, 29 November 2016 (UTC)

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,

]; MaLa (talk) 10:31, 4 April 2019 (UTC)

Maybe related to phab:T260201. Valerio Bozzolan (talk) 13:59, 18 December 2020 (UTC)

Hide Sidebar Menu Items for locked down pages

I've successfully implemented the Lockdown extension to prevent pages from being accessed. However, the links that the user cannot access are still shown in the Sidebar.

Is there a way to remove links from the sidebar? (i.e. can I hide links based on the pages they point to that are part of namespaces that are not able to be accessed by the current logged in user?) 50.32.27.234 15:22, 3 March 2014 (UTC)

Do you mind sharing how you got this to work? 76.68.137.45 06:33, 27 October 2014 (UTC)

Well, this IP did not get it to work. I believe the UserFunctions extension is the best way to display per group links in the sidebar. [[kgh]] (talk) 16:23, 27 October 2014 (UTC)

Restrict createpage-right in Project-Namespace

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. Finswimmer (talk) 15:51, 4 March 2014 (UTC)

Did you ever get this to work? 76.68.137.45 06:33, 27 October 2014 (UTC)

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. [[kgh]] (talk) 22:49, 27 October 2014 (UTC)

I found a way using the Extension AbuseFilter with the following Filter and the "disallow" action:

(page_namespace = 0) &

(old_wikitext == "") &

!( 'sysop' in user_rights ) &

!contains_any(added_lines, "redirect")

It is certainly not perfect and notifies the user only after hitting "save", but it works. Halungg (talk) 15:31, 8 October 2020 (UTC)

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;</code> $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.... Rbirmann (talk) 15:21, 29 February 2016 (UTC)

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

define("NS_project", 1006);
define("NS_project_TALK", 1007);

$wgExtraNamespaces[NS_project] = "project";
$wgExtraNamespaces[NS_project_TALK] = "project_talk";   // underscore required


require_once "$IP/extensions/Lockdown/Lockdown.php";
$wgNamespacePermissionLockdown[NS_project]['*'] = array('sysop');
$wgNamespacePermissionLockdown[NS_project_TALK]['*'] = array('sysop');
$wgNonincludableNamespaces[] = NS_project;
$wgNonincludableNamespaces[] = NS_project_talk;

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

   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.

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

Maude's Ideology (talk) 06:13, 19 June 2018 (UTC)

if ( !isset( $_SERVER['REMOTE_ADDR'] ) OR $_SERVER['REMOTE_ADDR'] == '127.0.0.1'        ) {
        $wgGroupPermissions['*']['read'] = true;
        $wgGroupPermissions['*']['edit'] = true;
} else {
wfLoadExtension("Lockdown");

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

        $wgNamespacePermissionLockdown[NS_L2]['*'] = [ 'tech-L2', 'tech-L3' ];
        $wgNamespacePermissionLockdown[NS_L3]['*'] = [ 'tech-L3' ];
}

$wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;
$wgVirtualRestConfig['modules']['global']['forwardCookies'] = true;
$wgVirtualRestConfig['modules']['restbase']['forwardCookies'] = true;
$wgVisualEditorParsoidForwardCookies = true;

{"name":"parsoid","hostname":"testwiki.wiki.internal","pid":1173,"level":60,"logType":"fatal/request","wiki":"wiki$0","title":"L2:Test","oldId":null,"reqId":"8b724680-f202-11ea-ae20-13b87b0d14d7","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36","msg":"API response Error for TemplateRequest: request=; error={\"code\":\"accessdenied\",\"info\":\"You are not allowed to view L2:Test.\",\"*\":\"See http://testwiki.wiki.internal/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes.\"}","stack":"Error: API response Error for TemplateRequest: request=; error={\"code\":\"accessdenied\",\"info\":\"You are not allowed to view L2:Test.\",\"*\":\"See http://testwiki.wiki.internal/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes.\"}\n    at TemplateRequest.ApiRequest._errorObj (/var/lib/parsoid/lib/mw/ApiRequest.js:342:9)\n    at TemplateRequest._handleJSON (/var/lib/parsoid/lib/mw/ApiRequest.js:554:16)\n    at TemplateRequest.ApiRequest._logWarningsAndHandleJSON (/var/lib/parsoid/lib/mw/ApiRequest.js:447:7)\n    at TemplateRequest.ApiRequest._handleBody (/var/lib/parsoid/lib/mw/ApiRequest.js:483:7)\n    at TemplateRequest.ApiRequest._requestCB (/var/lib/parsoid/lib/mw/ApiRequest.js:420:8)\n    at Request._callback (/var/lib/parsoid/lib/mw/ApiRequest.js:332:35)\n    at Request.self.callback (/var/lib/parsoid/node_modules/request/request.js:185:22)\n    at Request.emit (events.js:315:20)\n    at Request.<anonymous> (/var/lib/parsoid/node_modules/request/request.js:1154:10)\n    at Request.emit (events.js:315:20)\n    at IncomingMessage.<anonymous> (/var/lib/parsoid/node_modules/request/request.js:1076:12)\n    at Object.onceWrapper (events.js:421:28)\n    at IncomingMessage.emit (events.js:327:22)\n    at endReadableNT (_stream_readable.js:1220:12)\n    at processTicksAndRejections (internal/process/task_queues.js:84:21)","longMsg":"API response Error for TemplateRequest: request=; error={\"code\":\"accessdenied\",\"info\":\"You are not allowed to view L2:Test.\",\"*\":\"See http://testwiki.wiki.internal/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes.\"}","levelPath":"fatal/request","time":"2020-09-08T18:38:53.628Z","v":0}

load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:141 JQMIGRATE: Migrate is installed with logging active, version 3.0.1
VM1016:150 This page is using the deprecated ResourceLoader module "jquery.tabIndex".
(anonymous) @ VM1016:150
runScript @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:13
execute @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:15
doPropagation @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:7
requestIdleCallback (async)
requestPropagation @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:8
setAndPropagate @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:8
implement @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:20
(anonymous) @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:1
load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:130 GET http://testwiki.wiki.internal/testwiki.wiki.internal/v1/page/html/L2%3ATest?redirect=false&stash=true 500
send @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:130
ajax @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:125
jQuery.ajax @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:144
requestParsoidData @ VM1016:148
requestPageData @ VM1016:145
(anonymous) @ VM1016:125
mightThrow @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:48
process @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:49
setTimeout (async)
(anonymous) @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:49
fire @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:45
add @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:46
(anonymous) @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:50
jQuery.Deferred @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:152
then @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:49
activateTarget @ VM1016:125
activatePageTarget @ VM1016:127
activateVe @ VM1016:135
onEditTabClick @ VM1016:134
dispatch @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:69
elemData.handle @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:65
VM1016:148 RESTBase load failed: error
(anonymous) @ VM1016:148
mightThrow @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:48
process @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:49
setTimeout (async)
(anonymous) @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:49
fire @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:45
fireWith @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:47
fire @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:47
fire @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:45
fireWith @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:47
done @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:126
(anonymous) @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:130
load (async)
send @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:130
ajax @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:125
jQuery.ajax @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:144
requestParsoidData @ VM1016:148
requestPageData @ VM1016:145
(anonymous) @ VM1016:125
mightThrow @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:48
process @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:49
setTimeout (async)
(anonymous) @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:49
fire @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:45
add @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:46
(anonymous) @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:50
jQuery.Deferred @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:152
then @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:49
activateTarget @ VM1016:125
activatePageTarget @ VM1016:127
activateVe @ VM1016:135
onEditTabClick @ VM1016:134
dispatch @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:69
elemData.handle @ load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:65

<?php

######################################################################################################################################
#CORE
######################################################################################################################################


$wgSitename = "testwiki";
$wgSecretKey = "c5ded9cb55cc68669f706ad0fffbb9e7aba3e7b7f5664b2c7448259e274d9dd6";
$wgUpgradeKey = "11640ab816b1bb22";

#Short URLs and Search Config
$wgScriptPath = "";
$wgArticlePath = "/$1";
$wgUsePathInfo = true;
$wgScriptExtension = ".php";


$wgServer = "http://testwiki.wiki.internal";


$wgResourceBasePath = $wgScriptPath;


######################################################################################################################################
#DATABASE
######################################################################################################################################


$wgDBtype = "mysql";
$wgDBserver = "mariadb";
$wgDBname = "wikis";
$wgDBuser = "wikisql";
$wgDBpassword = "c493905d0e184ffd23e4c53420dc9cb6d557892d";
$wgDBprefix = "";
$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=binary";
$wgDBmysql5 = false;


######################################################################################################################################
#GENERAL
######################################################################################################################################

// Skin
wfLoadSkin( 'Vector' );
$wgDefaultSkin='vector';


######################################################################################################################################
#Additional Mediawiki User Groups: tech-*
######################################################################################################################################


###Tech/Engineering Groups (CREATE)
$wgGroupPermissions['tech-L2'] = $wgGroupPermissions['user'];
$wgGroupPermissions['tech-L3'] = $wgGroupPermissions['user'];


######################################################################################################################################
#Custom Namespaces
######################################################################################################################################


define('NS_L2' , 3002);
define('NS_L2_TALK' , 3003);
define('NS_L3' , 3004);
define('NS_L3_TALK' , 3005);


$wgExtraNamespaces[NS_L2] = 'L2';
$wgExtraNamespaces[NS_L2_TALK] = 'L2 Talk';
$wgExtraNamespaces[NS_L3] = 'L3';
$wgExtraNamespaces[NS_L3_TALK] = 'L3 Talk';

######################################################################################################################################
#Lockdown
######################################################################################################################################

wfLoadExtension("Lockdown");

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

$wgNamespacePermissionLockdown[NS_L2]['*'] = [ 'tech-L2', 'tech-L3' ];
$wgNamespacePermissionLockdown[NS_L3]['*'] = [ 'tech-L3' ];


#####################################################################################################################################
#VisualEditor, Restbase and Parsoid
######################################################################################################################################


##Global Rest Config
  $wgVirtualRestConfig = [
    'modules' => [],
    'global' => [
      'domain' => 'testwiki.wiki.internal',
      'timeout' => 360,
      'forwardCookies' => true,
      'HTTPProxy' => null,
      ]
    ];


 # Rest config for Parsoid
 $wgVirtualRestConfig['modules']['parsoid'] = array(
  'url' => 'http://localhost:8142',
  'domain' => 'testwiki.wiki.internal',
  'forwardCookies' => true,
  'restbaseCompat' => false
  );


 ## Rest Config for Restbase
 $wgVirtualRestConfig['modules']['restbase'] = array(
  'url' => 'http://localhost:7231',
  'domain' => 'testwiki.wiki.internal',
  'forwardCookies' => true,
  'parsoidCompat' => false
 );


#VisualEditor
 wfLoadExtension('VisualEditor');
 $wgVisualEditorParsoidAutoConfig = false;
 $wgVisualEditorAllowLossySwitching = false;
 $wgVisualEditorFullRestbaseURL = 'http://testwiki.wiki.internal/testwiki.wiki.internal/';
 $wgVisualEditorRestbaseURL = 'http://localhost:7231/testwiki.wiki.internal/v1/page/html/';
 $wgVisualEditorParsoidForwardCookies = true;


 $wgDefaultUserOptions['visualeditor-editor'] = "visualeditor";
 $wgDefaultUserOptions['visualeditor-enable'] = 1;
 $wgDefaultUserOptions['visualeditor-newwikitext'] = 1;

 $wgVisualEditorAutoAccountEnable = true;
 $wgVisualEditorShowBetaWelcome = false;
 $wgVisualEditorEnableDiffPage = true;
 $wgVisualEditorEnableWikitext = true;

 $wgVisualEditorNamespaces = array_merge($wgContentNamespaces, array( NS_TALK, NS_USER, NS_USER_TALK, NS_L2, NS_L2_TALK, NS_L3, NS_L3_TALK) );
 $wgVisualEditorAvailableNamespaces = array_fill_keys($wgVisualEditorNamespaces, true);

#
# Simple RESTBase config for Mediawiki Container
# https://www.mediawiki.org/wiki/RESTBase/Installation
#
# - cassandra DB
# - parsoid at http://localhost:8142
# - wiki at http://testwiki.wiki.internal/api.php
#
# - proxied via nginx, available via
# - http://hostname/api/rest_v1/
#
services:
  - name: restbase
    module: hyperswitch
    conf:
      port: 7231
      salt: 988881adc9fc3655077dc2d4d757d480b5ea0e11
      default_page_size: 125
      user_agent: RESTBase
      ui_name: RESTBase
      ui_url: https://www.mediawiki.org/wiki/RESTBase
      ui_title: RESTBase docs
      spec:
        x-request-filters:
          - path: lib/security_response_header_filter.js
          - path: lib/normalize_headers_filter.js
        x-sub-request-filters:
          - type: default
            name: http
            options:
              allow:
                - pattern: http://localhost/api.php
                  forward_headers: true
                - pattern: http://localhost:8142
                  forward_headers: true
                - pattern: http://testwiki.wiki.internal/api.php
                  forward_headers: true
                - pattern: http://testwiki.wiki.internal:8142
                  forward_headers: true

                - pattern: /^https?:\/\//
        paths:
          /{domain:testwiki.wiki.internal}/{api:v1}:
            x-modules:
              - spec:
                  info:
                    version: 1.0.0
                    title: Wikimedia REST API
                    description: Welcome to your RESTBase API.
                  x-route-filters:
                    - path: ./lib/normalize_title_filter.js
                      options:
                        redirect_cache_control: 's-maxage=0, max-age=86400'
                  paths:
                    /page:
                      x-modules:
                        - path: v1/content.yaml
                          options:
                            response_cache_control: 's-maxage=0, max-age=86400'
                        - path: v1/common_schemas.yaml # Doesn't really matter where to mount it.
                    /transform:
                      x-modules:
                        - path: v1/transform.yaml
                    /media:
                      x-modules:
                        #- path: v1/mathoid.yaml
                        #  options:
                        #    host: http://localhost:10042

          /{domain:testwiki.wiki.internal}/{api:sys}:
            x-modules:
              - path: projects/proxy.yaml
                options:
                  backend_host_template: '{{"/{domain}/sys/legacy"}}'
              - spec:
                  paths:
                    /table:
                      x-modules:
                        - path: sys/table.js
                          options:
                            conf:
                              version: 1
                              backend: cassandra
                              hosts:
                                - cassandradb
                              pool_idle_timeout: 20000
                              retry_delay: 250
                              retry_limit: 10
                              show_sql: false
                              keyspace: system
                              defaultConsistency: localOne
                              localDc: datacenter1
                              datacenters:
                                - datacenter1
                              storage_groups:
                                - name: local
                                  domains: /./
                    /legacy/key_value:
                      x-modules:
                        - path: sys/key_value.js
                    /legacy/page_revisions:
                      x-modules:
                        - path: sys/page_revisions.js
                    /post_data:
                      x-modules:
                        - path: sys/post_data.js
                    /action:
                      x-modules:
                        - path: sys/action.js
                          options:
                            apiUriTemplate: "{{'http://localhost/api.php'}}"
                            baseUriTemplate: "{{'http://localhost:7231/{domain}/v1'}}"
                    /page_save:
                      x-modules:
                        - path: sys/page_save.js
                    /events:
                      x-modules:
                        - path: sys/events.js
                    /parsoid:
                      x-modules:
                        - path: sys/parsoid.js
                          options:
                            parsoidHost: http://localhost:8142
                            grace_ttl: 1000000
                    #/mathoid:
                    #  x-modules:
                    #    - path: sys/mathoid.js
                    #      options:
                    #        host: http://localhost:10042

# Finally, a standard service-runner config.
info:
  name: restbase

logging:
  name: restbase
  level: warn
  streams:
    - type: stdout


num_workers: 0

worker_heartbeat_timeout: 300000
num_workers: 2

logging:
    name: parsoid
    level: warn

services:
  - module: lib/index.js
    entrypoint: apiServiceWorker
    conf:
        mwApis:
        - uri: 'http://localhost/api.php'
          domain: 'testwiki.wiki.internal'
        serverPort: 8142

# nginx http config for Mediawiki server
#
# this config-file is updated during container-startup
# 'testwiki.wiki.internal' is replaced globally with the FQDN of the Wiki
#


##############################
### UPSTREAMS
##############################

# restbase
upstream restbase {
  server 127.0.0.1:7231;
  keepalive 32;
}
map $request_uri $restbasequeryapi {
  default "xx";
  "~/api/rest_v1/(?<xrestbasequery>.*)$" "$xrestbasequery";
}
map $request_uri $restbasequerylegacy {
  default "xx";
  "~/testwiki.wiki.internal/v1/(?<xrestbasequery>.*)$" "$xrestbasequery";
}
map $request_uri $imageDownloadAttachment {
  default "";
  "~/images/.*(\?|&)download(=|&).*$" "attachment";
}


##############################
### MAIN HTTP SERVER
##############################

server {

  ##############################
  ### HTTP Globals
  ##############################

  server_name _;
  listen 80;
  root /var/lib/mediawiki;
  client_max_body_size 100m;
  fastcgi_connect_timeout 10s;

  set $no_cache "0";

  ##############################
  ### Proxy Restbase, Mathoid
  ##############################

  location /api/rest_v1/ {
    proxy_max_temp_file_size 0;
    proxy_buffer_size 64k;
    proxy_buffers 4 64k;
    proxy_http_version 1.1;
    proxy_pass http://restbase/testwiki.wiki.internal/v1/$restbasequeryapi;
    set $no_cache "1";
  }

  location /testwiki.wiki.internal/v1/ {
    proxy_max_temp_file_size 0;
    proxy_buffer_size 64k;
    proxy_buffers 4 64k;
    proxy_http_version 1.1;
    proxy_pass http://restbase/testwiki.wiki.internal/v1/$restbasequerylegacy;
    set $no_cache "1";
  }

  location /api/mathoid/ {
    proxy_max_temp_file_size 0;
    proxy_buffer_size 64k;
    proxy_buffers 4 64k;
    proxy_http_version 1.1;
    proxy_pass http://127.0.0.1:10042/;
    set $no_cache "1";
  }

 location /rest.php/ {
    proxy_max_temp_file_size 0;
    proxy_buffer_size 64k;
    proxy_buffers 4 64k;
    proxy_http_version 1.1;
    try_files $uri $uri/ /rest.php?$query_string;
    set $no_cache "1";
 }

 # Bypass cache if flag is set
 fastcgi_no_cache $no_cache;
 fastcgi_cache_bypass $no_cache;
 proxy_cache_bypass $no_cache;
 proxy_no_cache $no_cache;

  ##############################
  ### General Requests
  ##############################

  location ~ \.htaccess { deny all; }
  location ^~ /install-mw.sh { return 403; }
  location ^~ /update-mw.sh { return 403; }
  location ^~ /runjobs-mw.sh { return 403; }
  location ^~ /bootstrap/1_env.php { return 403; }

  location ^~ /bootstrap.php {
    # extended php-timeout ( e.g. for update.php )
    fastcgi_read_timeout 200s;
    fastcgi_send_timeout 200s;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
  }

  location /images {
    # enable CORS access to this dir from other origins
    add_header Access-Control-Allow-Origin "*";
    add_header Access-Control-Expose-Headers "Age,Date,X-Cache,X-Varnish";

    # allow downloads via Media Viewer
    add_header Content-Disposition $imageDownloadAttachment;

    # the hosting root-dir is updated/set during container startup
    root /wiki-shared/testwiki/storage;

    # set the 'Expires' header for 90days of image-caching to reverse-proxies
    # proxies often have their own expiry-lifetime for hot/cold cache items
    expires 90d;
  }

  location / {
    try_files $uri @rewrite;
  }

  location ^~ /mw-config/ {
    internal;
  }

  location @rewrite {
    rewrite ^/(.*)$ /index.php;
  }

  location ^~ /maintenance/ {
    internal;
  }

  location = /_.gif {
    expires max;
    empty_gif;
  }

  location ^~ /cache/ {
    internal;
  }

  ##############################
  ### PHP Config
  ##############################

  location ~ ^/system/nginxping$ {
    access_log off;
    return 200 'pong :-)';
  }

  location ~ ^/system/phpstatus {
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_index index.php;
  }

  location ~ \.php$ {
    fastcgi_pass unix:/run/php-fpm.sock;
    fastcgi_split_path_info ^(.+\.php)(/.*)$;
    include fastcgi_params;
    fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;
    fastcgi_param HTTPS off;
    fastcgi_index index.php;
  }

}

Calebgcooper (talk) 17:41, 7 September 2020 (UTC)

In summary: Custom Namespace + Lockdown + SimpleBatchUpload + SemanticACL produces the overall effect.

Hi, I just updated to MediaWiki 1.37 and get now the following error:

Use of User::getEffectiveGroups was deprecated in MediaWiki 1.35. [Called from MediaWiki\Extensions\Lockdown\Hooks::onGetUserPermissionsErrors in /var/www/html/extensions/Lockdown/src/Hooks.php at line 123] in /var/www/html/includes/debug/MWDebug.php
 on line 375

I think the code should be fixed here. I hope someone could help out. 134.3.98.147 (talk) 12:31, 6 December 2021 (UTC)