Extension talk:Lockdown
Contents
 First page |
 Previous page |
 Next page |
 Last page |
I don't think it was mentioned in the README file, but one should be careful about specifying the page name when using $wgSpecialPageLockdown. Say I want to block read access to Special:UncategorizedCategories, then I would naturally do something like this:
$wgSpecialPageLockdown['UncategorizedCategories'] = array('bureaucrat');
This is incorrect. You need to replace 'UncategorizedCategories' with 'Uncategorizedcategories'.
This is true for every special page with a title being the concatenation of two or more words such as 'UncategorizedCategories' above.
It is possible to lockdown the special namespace? I do not want users having access to the Special namespace, so I wrote this in LocalSettings.php:
$wgNamespacePermissionLockdown[NS_SPECIAL]['read'] = array('bureaucrat');
I seem to be able to access special pages through a user that is not in group bureaucrat.
It does not make sense to do this. Logging into or out of a wiki already requires access to special pages. I suggest to lock down only selected special pages.
My plan was to put the login,logout and other specific special pages in the $wgWhitelistRead array and then block the Special namespace. Then all the special pages would be blocked to users except a few of them (like login and logout). This approach doesn't seem to work.
I've never studied the php language, but I was able to look at the Lockdown.php file and make sense of it. For my needs, I ended up commenting out the part where pages specified in the $wgWhitelistRead array cannot be denied read acces.
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.
- I'm using mediawiki 1.23 on Fedora
- I created a namespace called "project".
- I properly installed the extension (checked Special:Version).
- I put this in the LocalSettings.php file:
$wgNamespacePermissionLockdown[NS_PROJECT]['*'] = array('sysop');
- I created a page at project:AA
- I can still access the page project:AA from a non sysop user.
It appears that this extension is no longer functional. Any ideas?
The extension works for me.
About the project namespace, see $wgMetaNamespace.
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?)
Do you mind sharing how you got this to work?
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.
See idea at m:Grants:IdeaLab/A place to work together.
- If you'd like to develop the Lockdown extension, you may get a few thousands dollars to do it.
- If you use the Lockdown extension, please document in bugzilla reports what's missing for it to satisfy the requirements.
(Also posted on mediawiki-l.)
Nemo, I've done a bit of work in using lockdown.
See: Extension:NSFileRepo
You're free to edit the idea on Meta, add yourself as participant and then (if you wish) bring it up as actual (IEG) grant request, ideally together with some more participants. :)
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.
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');
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
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.
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.
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)
hi please update this extension to support newer releases of mediawiki please.
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
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,
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
"Not absolutely sure but this seems more correct"
$wgNamespacePermissionLockdown[NS_USER]['edit'] = array('syop');
But yours might work also. Cheers,
thank you sir, I will try this!
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?
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', );
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!
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
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?
First page |
Previous page |
Next page |
Last page |
