Extension talk:Lockdown/LQT Archive 1

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.

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:

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

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)

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)

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)

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

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

Re: 2 Small bugs, Recording user name to history and group name with a space character
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)

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)

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?

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)

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; $wgGroupPermissions['sysop']['suppressredirect'] = true; require_once( "$IP/extensions/Lockdown/Lockdown.php" );
 * 1) despite documented defaults administrators do not have 'suppressredirect' by default

212.147.27.179 14:01, 12 May 2011 (UTC)
 * This has already been fixed if you download the latest snapshot (the "trunk" version) of Lockdown. -- Skiz zerz  23:19, 12 May 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)

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)