Talk:NamespacePermissions Extension
Requesting clarification and finding errors
Hello all,
- All I wanted is to do the followings:
- Disable any anonymous access altogether
- "Logged in" users have "READONLY" access and even can't use Talk pages.
- Create bunch of custom namespaces (e.g. MyNS1, MyNS2, etc.)
- Use NameSpacePermission Extension to make it automatically create groups (nsMyNS1RW, nsMyNS1RO, nsMyNS2RW, nsMyNS2RO, etc.)
- As soon as I add a user into one of the groups (e.g. Add user1 to nsMyNS1RW), I expect that user1 can create/Manage any article start with "MyNS1:" (e.g. MyNS1:Test Page, MyNS1:The Page can be only accessible by the users in nsMyNS1RW or nsMyNS1RO group)
- All I wanted is to do the followings:
- I simply placed NamespacePermissions.php under .\extensions folder.
- Updated the localsettings as following:
// Create Custom Namespaces
$wgExtraNamespaces[1001] = "MyNS1";
$wgExtraNamespaces[1002] = "MyNS1_Talk";
$wgExtraNamespaces[2001] = "MyNS1";
$wgExtraNamespaces[2002] = "MyNS1_Talk";
// Overriding Implicit group for all visitors
$wgGroupPermissions['*' ]['createaccount'] = false; //prevents new registrations from anonymous users
//$wgGroupPermissions['*' ]['read'] = false; // Optional depending on the security requirement
$wgGroupPermissions['*' ]['edit'] = false;
$wgGroupPermissions['*' ]['createpage'] = false;
$wgGroupPermissions['*' ]['createtalk'] = false;
// Double overriding on Commandline mode
if ($wgCommandLineMode) {
$wgGroupPermissions['*']['read'] = true;
}
# Pages anonymous (not-logged-in) users may see
$wgWhitelistRead = array( "Main Page", "Special:Userlogin", "-", "MediaWiki:Monobook.css", "*Support*" );
$wgDisableAnonTalk = true; # no discussion pages for anonyous users
// Overriding Implicit group for all logged-in accounts READONLY.
$wgGroupPermissions['user' ]['move'] = false;
$wgGroupPermissions['user' ]['read'] = true; // <--
$wgGroupPermissions['user' ]['edit'] = false;
$wgGroupPermissions['user' ]['createpage'] = false;
$wgGroupPermissions['user' ]['createtalk'] = false;
$wgGroupPermissions['user' ]['upload'] = true;
$wgGroupPermissions['user' ]['reupload'] = true;
$wgGroupPermissions['user' ]['reupload-shared'] = true;
$wgGroupPermissions['user' ]['minoredit'] = false;
// The following need to be defined after $wgExtraNamespaces
require_once( "extensions/NamespacePermissions.php" );
- With these settings, somehow user1 is simply treated as just "user" and have readonly for everything including MyNS1 even though user1 is on nsMyNS1RW group.
- Can you tell me what is wrong with this?
Thanks in advance.
Problem "Cannot modify header information..."
This facility looks like just what I need, but I followed the instructions and my main page was then besmirched with lots of errors along the lines of:
Warning: Cannot modify header information - headers already sent by (output started at /reuters/radt/local/MediaWiki/mediawiki-1.6.7/extensions/NamespacePermissions.php:59) in /reuters/radt/local/MediaWiki/mediawiki-1.6.7/includes/OutputPage.php on line 412
I'll try to contact the originators to see what this means - I'm pretty new to this stuff and don't speak PHP (yet)!
eof
Line 59 seems to be the last line of the file. Please check that the symbols "?>" (PHP closing "brace") are the last symbols of the file. If they are not (one space or a linefeed is bad enough) the extra symbols will go to the output, and setting the headers afterwards will fail.
dawald
What a great plugin, exaclty what I was looking for. Unfortunatly it doesn't seem to work. I get the following error message: "Warning: call_user_func(): First argument is expected to be a valid callback in /wiki/includes/Setup.php on line 327" I'm using Verion 1.6.7 without other extensions.
fixed
you found an interesting bug/feature of MediaWiki - thank you! (it seems that the object for the current user get created before the extension functions are called).
please copy the source from the content page again. it should work now.
All Pages
While the pages themselves seem to be protected with this extension, what is the possibility that the entries in the special page "All Pages" be hidden unless the user is signed in with a login that allows access to the protected namespace? Otherwise, the number and names of pages within a protected namespace are available.
12.223.26.3 21:28, 22 July 2006 (UTC)
- There's also a lot of other pages that can show article names. See Hidden pages#Making it secure for details. Ilya Voyager 11:17, 8 October 2006 (UTC)
Security Issue: How to Prevent Public Searching
When using NamespacePermissions Extension it is possible for every user to include the protected namespaces when searching. For every page hit the wiki will show (possibly secret) text from protected pages.
I will describe how to patch the system, in order to make searching in protected namespaces only possible for users in the provided (protected) groups.
The Special:Search page first make a list of all searchable namespaces and then remove those not included in the user's preferences or in the "power search" settings.
The approach was to reduce the list of all searchable namespaces and not include protected namespaces for users that have no permission.
Version
- Current patch version: 1.1 (27 July 2006)
- Tested and works with: MediaWiki 1.7.1
- Author: Andershhh
Use with care. No guarantee. Please try, test and give feedback.
Change file SearchEngine.php
You will have to change a few lines in the file includes/SearchEngine.php, start at row 159. A few more lines are included for orientation.
It should be noted that changes to any files other than LocalSettings.php might need to be overwritten when upgrading to a newer mediawiki version. --Umassthrower
SearchEngine.php (old)
/**
* Make a list of searchable namespaces and their canonical names.
* @return array
* @access public
*/
function searchableNamespaces() {
global $wgContLang;
$arr = array();
foreach( $wgContLang->getNamespaces() as $ns => $name ) {
if( $ns >= NS_MAIN ) {
$arr[$ns] = $name;
}
}
return $arr;
}
SearchEngine.php (new)
/**
* Make a list of searchable namespaces and their canonical names.
* Updated 07/27/2006 by andershhh: Check user user rights and
* only return those namespaces the user has permission to.
* @return array
* @access public
*/
function searchableNamespaces() {
global $wgContLang, $wgUser;
$arr = array();
foreach( $wgContLang->getNamespaces() as $ns => $name ) {
if( $ns >= NS_MAIN ) {
$userAllowed = $wgUser->isAllowed("ns{$ns}_read");
$groupExists = in_array("ns{$name}RO", $wgUser->getAllGroups());
if ( $userAllowed || !$groupExists ) {
$arr[$ns] = $name;
}
}
}
return $arr;
}
Sample LocalSettings.php
// Extra namespaces, that should be protected
$wgExtraNamespaces = array(100 => "Brf", 101 => "Brf_Talk");
// Include extension.
require('extensions/NamespacePermissions.php');
// Extra namespaces, that should not be protected.
$wgExtraNamespaces[102] = "Tmp";
// Allow subpages
$wgNamespacesWithSubpages[100] = true;
// Make namespaces searchable by default
$wgNamespacesToBeSearchedDefault[NS_PROJECT] = 1;
$wgNamespacesToBeSearchedDefault[100] = 1;
$wgNamespacesToBeSearchedDefault[102] = 1;
The order of the first three variables are important.
Andershhh 14:18, 27 July 2006 (UTC)
Patch for SpecialRecentchanges.php
This patch for SpecialRecentchanges.php hides the recent changes comments from users without reading permissions
global $wgExtraNamespaces;
...
# Namespace filtering
foreach ( $wgExtraNamespaces as $num => $title ) {
if (!($wgUser->isAllowed("ns".$num."_read"))) {
$hidem .= ' AND rc_namespace!='.$num;
}
}
...
Patch for SpecialWhatlinkshere.php
Adapted from the above patch for SpecialRecentchanges.php --69.145.178.105 03:09, 14 October 2006 (UTC)
global $wgUser;
global $wgExtraNamespaces;
...
// Make the query
$plConds = array( ... );
$tlConds = array( ... );
foreach ( $wgExtraNamespaces as $num => $title ) {
if (!($wgUser->isAllowed("ns".$num."_read"))) {
$plConds[] = 'page_namespace!='.$num;
$tlConds[] = 'page_namespace!='.$num;
}
}
...
Re Preventing public searching and hiding changes
If it comes to making a patch, a more global solution would be using Title::userCan method (which runs userCan hooks) rather than filtering the list of namespaces.
Having hacked SpecialRecentchanges.php and SearchEngine.php - do you think it will work?
It is a better solution because there can be other means to protect pages from being viewed, may be individually (I am about to implement such a system now) - in which case pages have to be handled separately.
Oduvan 20:29, 29 July 2006 (UTC)
Transcluding
Apart from the search problem, there is another flaw : if a page name is known, there one can use {{:Forbidden_Namespace:Secret_page}} in a authorised namespace and simply get the content this way.
to prevent or at least reduce this problem, there would be need that the special:allpages hides the page list in this namespace for all not-in-the-required-group-to-view users.
DarkoNeko 20:02, 13 August 2006 (UTC)
- To completely avoid this problem you can forbid transclusion of pages in custom namespaces.
- In Parser.php, look for the following code (it starts at line 2642 in ver. 1.6.6; line 2829 in 1.7.1):
$articleContent = $this->fetchTemplate( $title );
if ( $articleContent !== false ) {
$found = true;
$text = $articleContent;
$replaceHeadings = true;
}
- and add the following right below it:
# Don't allow inclusion from custom namespaces
if ( $title->getNamespace() >= 100 ) {
$found = true;
$text = $linestart . wfMsg( 'templatenotincluded' );
}
- I have improved the trick. Now transclusions are allowed in the same namespace, but forbidden between namespaces. I.e. you can transclude an article from namespace A into an article from namespace A, but can't into an article from namespace B. However, you can define a namespace (or list of namespaces), articles from which are allowed to be transcluded everywhere.
global $wgNamespacesAllowedForTransclusion;
if ( ($title->getNamespace() >= 100) && ($title->getNamespace() != $this->mTitle->getNamespace()) && (!$wgNamespacesAllowedForTransclusion[$title->getNamespace()]) ) {
$found = true;
$text = $linestart . wfMsg( 'templatenotincluded' );
}
- As you can see, you define a list of allowed-to-be-transcluded-namespaces using $wgNamespacesAllowedForTransclusion variable (in LocalSettings.php). Example:
$wgNamespacesAllowedForTransclusion[100] = 1;
- So, it works exactly like $wgNamespacesToBeSearchedDefault variable.
- Enjoy.
- --Oscar 6 22:07, 8 November 2006 (UTC)
Length of Namespace limitation
I found that the plugin doesn't work with namespaces that are longer than 12 characters. Is this a limitation of the extension or wikimedia itself?
The group name would get truncated in the userlist if the ns*group*RW or ns*group*RO names are longer than 16 characters.
--Thelastguardian 03:10, 17 August 2006 (UTC)
- I've stumbled upon the very same problem. I've dug through tons of code just to find out that it was database limitation: turns out, the ug_group field in the user_groups table has char(16) type, meaning it can't contain more than 16 characters. I changed it to char(128) and it worked like a miracle. Phew.
- I find it strange that this is just to be found in the discussion page. I was lucky to find it quickly but it should be on the content page. I will put this under "Pitfalls".
- For those of you that would prefer not to have to research how to implement Oscar's fix, here it is:
alter table mw_user_groups modify ug_group CHAR(128);
- Incidentally, I also find it strange that this is where I had to find this information.
- --dustin 12/01/2006
Version Info
I added the following lines to your extensions/NamespacePermissions.php file to show up the extension-info on Special:Version:
$wgExtensionCredits['other'][] = array( "name" => "NamespacePermissions", "author" => "Petr Andreev", "url" => "http://meta.wikimedia.org/wiki/NamespacePermissions_Extension", "description" => "Permission set per Namespace" );
right after
$wgExtensionFunctions[] = "wfNamespacePermissions";
It would be nice to have it in standard source code :-)
Security Issue: XML Export
It looks that XML Export module doesn't respect user rights of this extension. So you SHOULD either turn off XML Export or write a patch to Export.php like one above. Ilya Voyager 11:05, 8 October 2006 (UTC)
Change the following in SpecialExport.php:
$exporter->pageByName( $page );
to:
$title = Title::newFromText( $page );
if ($title->userCanRead()) {
$exporter->pageByName( $page );
}
Problem: Writeable namespace for anonymous user
In my setup, anonymous users have the edit right set to false. I wanted to create a namespace with edit rights for anonymous users and added $wgGroupPermissions['*']['ns100_edit'] = true; to LocalSettings.php. That doesn't seem to work. Maybe the global edit = false configuration overrides the namespace-specific setting? Do I have to set edit = false for every single (default) namespace to work around this? 147.142.207.95 14:04, 24 October 2006 (UTC)
Formatting changes to installation instructions
I reformatted the Installation and usage instructions, hopefully with no content changes. Using an HTML list instead of a wiki list allows the code line example to appear more readably, and to maintain list item numbering around the code line example (which will not work with a wiki list). I also added links to the various filename, variable name, and page name references, to help me as I learn this material. I hope others find this format change useful. Teratornis 01:28, 14 November 2006 (UTC)
Error: Warning: Invalid argument supplied for foreach() in ..../extensions/NamespacePermissions.php on line 40
Hi,
On installing the NamespacePermissions.php script "vanilla", without first defining any extra namespaces, the following error occurs:
Warning: Invalid argument supplied for foreach() in (path)/extensions/NamespacePermissions.php on line 40
This is quite trivial to avoid, and for completeness, you might want to include this in your script:
if($wgExtraNamespaces <> "") {
foreach ( $wgExtraNamespaces as $num => $title ) {
$wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_edit" ] = true;
$wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_read" ] = true;
$wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_create" ] = true;
$wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_move" ] = true;
$wgGroupPermissions[ "ns{$title}RO" ][ "ns{$num}_read" ] = true;
}
}
(my additions emboldened in the above)
Regards, Steve
- I wrote a slightly different workaround, posted below:
if ( $wgExtraNamespaces == NULL ) {}
else {
foreach ( $wgExtraNamespaces as $num => $title ) {
$wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_edit" ] = true;
$wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_read" ] = true;
$wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_create" ] = true;
$wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_move" ] = true;
$wgGroupPermissions[ "ns{$title}RO" ][ "ns{$num}_read" ] = true;
}
}
- Thanks, ^demon
Problem: The funcktion namespacePermissionsCheckNamespace is never called
I have the installed the extension in our Wiki (1.5.x), but it seems that the function namespacePermissionsCheckNamespace() is never called. Does this extension work in MediaWiki 1.5.x?
Error message patch in OutputPage.php
Great extension! However, I have noticed that the error message you get for users that don't have read access to a secured namespace, so I patched OutputPage.php to fix it. Currently, you get a message like The action you have requested is limited to users in one of the groups "*", "user". (even though those users obviously don't have access. This was written against 1.8.1, and assumes (as does the extension) that namespaces over 100 are going to have limited access.
For the correct groups, change:
function loginToUse() {
global $wgUser, $wgTitle, $wgContLang;
if( $wgUser->isLoggedIn() ) {
$this->permissionRequired( 'read' );
return;
}
...
to:
function loginToUse() {
global $wgUser, $wgTitle, $wgContLang;
if( $wgUser->isLoggedIn() ) {
if ( ( $ns = $wgTitle->getNamespace() ) >= 100 ) {
$this->permissionRequired("ns{$ns}_read");
} else {
$this->permissionRequired( 'read' );
}
return;
}
...
Security Issue: Special Pages
I've been working with the extension and all of the above patches thus far, but it would seem that all of these are simply fingers in the dike: many (if not all) of the special pages would have to be modified as well, as they all generally display information.
I'm starting to think that this really needs to be rolled into MediaWiki itself. Thoughts? --Cmreigrut 23:10, 23 January 2007 (UTC)
Where is the mod file?
After I installed mw 1.6.7 I went through the entire procedure to add the wgExtraNamespaces mod. I cannot find that file again. Would someone please direct me to the file? Or is it now necessary to grab the modified code from the body of the article? Thanks much. --JayEdgar 01:02, 31 January 2007 (UTC)