Extension talk:Lockdown
Contents
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" );
This has already been fixed if you download the latest snapshot (the "trunk" version) of Lockdown.
Nice! Great to see it fixed in a proper way ;-) Any chance the fix is propagated to the MW-1.16 snapshot?
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.
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)
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.
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.
Here is what I am getting in my upgrade from Mediawiki 1.16 to 1.17.
Fatal error: Call to undefined method MediaWiki::getAction() in... ...extensions/Lockdown/Lockdown.php on line 130
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
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?
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?
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,
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'];
Works on 1.17 as well, thanks for your effort
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
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.
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.
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?
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?
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.
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.
This also applies to inclusion {{:Page}} of redirects #REDIRECT:[[Protected:Page]].
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.
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.
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?
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!
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?
Update:
Now the extension works after doing this:
- Create a restricted namespace
- Create an article in that namespace with a user who has permission to do that
- Log-out (until now, nothing had changed; I'm still able to access sysop special pages and change user rights as an anonymous)
- Search for the article, created in step two
- Click on the result (there shouldn't be a result!)
- Now you get a restriction failure
- 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?
Update:
Now I have figured out the problem: It's something with the cookies. You can reproduce it in the following way:
- Log in to your wiki as an admin
- Close your browser
- Open your browser
- Check your cookies: there are two left: wikinameUserID and wikinameUserName
- Navigate to your wiki
- Go to Special Pages
- Here you can see all pages, you could see as an admin, even though you're not logged in!
- Deactivate the Lockdown Extension at LocalSettings.php
- Reload Special Pages
- Now, everything's OK; you're treated as an anonymous, without any rights
- Reactivate the Lockdown Extension at LocalSettings.php
- Reload Special Pages
- Now you're treated as an admin
- Delete one of that cookies mentioned above, it doesn't matter which one
- Now you're treated as an anonymous
You see: The Lockdown-Extension is the problem.
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.
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
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?
Apologies, it's also failing with Lockdown disabled. So it must be another thing.
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.
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.
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?
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.
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, 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.
