Extension talk:NamespacePermissions

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

Requesting clarification and finding errors

After installing MW 1.11.0rc1, the extension doesn't function anymore in my installation and the following error appeared: «Detected bug in an extension! Hook namespacePermissionsCheckNamespace failed to return a value; should return true to continue hook processing or false to abort.»--84.75.223.205 19:24, 6 September 2007 (UTC)

I am also having the same error after updating to 1.11. Any ideas on this???

HotMonkeyAC 17:25, 11 September 2007 (UTC)

Update: By changing line 63 to say return false; (or true) it seems to work. Can anyone else verify??

HotMonkeyAC 18:16, 11 September 2007 (UTC)

Yessss! I changed "null" to "true", now it's working fine! Thank you--84.75.223.205 12:58, 15 September 2007 (UTC)

I wasn't so lucky. I had not only to upgrade extensions/ParserFunctions.php (there is a new version available) but disable "Compress output if the browser supports it" (by commenting it out) which for some reason seems to break under my Dreamhost-installated Wiki. At least my wiki is up again...

GwynethLlewelyn 02:00, 21 March 2008 (UTC)

---

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)

• • 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.

Ypae 04:24, 7 February 2007 (UTC)

[RESOLVED] 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)!

Andthepharaohs 14:54, 20 July 2006 (UTC)

i can't tell you how much it annoys me to find the error i am getting dated 2006, and it isn't resolved.

148.87.1.172 14:12, 14 May 2009 (UTC)

RESOLUTION: use Extension:Lockdown

148.87.1.172 14:59, 14 May 2009 (UTC)

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.

Oduvan 12:25, 21 July 2006 (UTC)

Additional comment: This can be also the reason, why MediaWiki's Atom or RSS feed (about page changes) is not running or have syntax error in the XML header. After searching weeks about the xml error and parsing many forums, I deactived each of our 25 extensions. After activating (the wunderfull!) extension NamespacePermissions, the Atom feed failed. Then I read the topic of Oduvan (=>thanx a lot!) in the discussions and delete the two returns/linefeeds at the end of file NamespacePermissions.php :-) Now atom feed is running very well ...

---

62.159.123.206 11:33, 8 September 2012 (UTC)

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.

Oduvan 15:39, 21 July 2006 (UTC)

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 meta:Hidden pages#Making it secure for details. Ilya Voyager 11:17, 8 October 2006 (UTC)

Security Issue: How to Prevent Public Searching

When using Extension: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 SpecialAllpages.php

This patch for SpecialAllpages.php dumps the user to the (Main) namespace if they attempt to access one which they don't have access to.

In function "wfSpecialAllpages" in "includes/SpecialAllpages.php", put the following code at the top of the function, replacing everything down to (and including) the $namespace = 0; line. --71.224.196.239 09:11, 9 February 2007 (UTC)

	global $wgRequest, $wgOut, $wgContLang, $wgUser;

	# GET values
	$from = $wgRequest->getVal( 'from' );
	$namespace = $wgRequest->getInt( 'namespace' );

	$namespaces = $wgContLang->getNamespaces();

	$indexPage = new SpecialAllpages();

	$userAllowed = $wgUser->isAllowed("ns{$namespace}_read");
	$groupExists = in_array("ns{$namespaces[$namespace]}RO", $wgUser->getAllGroups());

	if( !array_key_exists($namespace, $namespaces) || (!$userAllowed && $groupExists))
		$namespace = 0;

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;
       }
}
...

The above patch is inserted into the showIndirectLinks() call, if it wasn't apparent. It prevents pages from a restricted namespace from showing up on other page's "What links here" pages.

The following patch can be inserted just after (or instead) of the above one and blocks access to the "What links here" page for users who don't have access to the page itself. (Note that I only did very limited testing on this) --71.224.196.239 08:08, 9 February 2007 (UTC)

if (!($wgUser->isAllowed("ns".$target->getNamespace()."_read")) &&
     ($target->getNamespace() >= 100)) {
    return;
}

Patch for all namespace dropdown menus

This patch fixes all the dropdown menus that contain namespaces, including that of the Special:Allpages page.

In "includes/XML.php", find the function "namespaceSelector" and replace

$s = "\n<select id='namespace' name='namespace' class='namespaceselector'>\n";
$arr = $wgContLang->getFormattedNamespaces();
if( !is_null($allnamespaces) ) {
	$arr = array($allnamespaces => wfMsg('namespacesall')) + $arr;
}
foreach ($arr as $index => $name) {
	if ($index < NS_MAIN) continue;

$name = $index !== 0 ? $name : wfMsg('blanknamespace');

with

$s = "\n<select id='namespace' name='namespace' class='namespaceselector'>\n";
$arr = $wgContLang->getNamespaces();
if( !is_null($allnamespaces) ) {
	$arr = array($allnamespaces => wfMsg('namespacesall')) + $arr;
}
foreach ($arr as $index => $name) {
	if ($index < NS_MAIN) continue;
	$userAllowed = $wgUser->isAllowed("ns{$index}_read");
	$groupExists = in_array("ns{$name}RO", $wgUser->getAllGroups());
	if ( !$userAllowed && $groupExists ) {
		continue;
	}
	$name = $index !== 0 ? strtr($name, '_', ' ') : wfMsg('blanknamespace');

You also need to replace the first line of the function with

global $wgContLang, $wgUser;

So far, it seems to work just fine for me. I will note, though that this fix doesn't prevent the user from manually entering the hidden namespace ID into the URL. See the Patch for SpecialRecentchanges.php and the Patch for SpecialAllpages.php sections for fixes for the rest of the page. --71.224.196.239 09:03, 9 February 2007 (UTC)

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; in 1.17 line 3264 and the function name is "fetchTemplateAndTitle"):

$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' );
}

--Oscar 6 23:55, 29 August 2006 (UTC)

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)

Most of the above will have been obsoleted (not to mention hard to implement) after version 1.10.0 with the introduction of the $wgNonincludableNamespacesVariable.

--Takophiliac 15:15, 10 March 2011 (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.

--Oscar 6 16:28, 25 August 2006 (UTC)

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".

--141.41.37.95 11:33, 25 September 2006 (UTC)

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

Also very annoying is that you can't use spaces in namespace-labels anymore. And even worse: When you've had given once a more-than-12-characters-name and set one user's rights for it, you can't remove the (abbreviated) entry in the "Member of"-list. How can I get rid of those obsolete entries? -Rob. (62.214.249.113 03:26, 18 October 2008 (UTC))

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" => "m:NamespacePermissions Extension",
   "description" => "Permission set per Namespace"
 );

right after

 $wgExtensionFunctions[] = "wfNamespacePermissions";

It would be nice to have it in standard source code :-)

Star

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

--Cmreigrut 23:04, 23 January 2007 (UTC)

It looks like this has been fixed. Lucasbfr 20:23, 8 February 2009 (UTC)

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)

It does. See my fix below for interacting with the talkright extension. It's possible that it's not just talkright that messes it up... --71.224.196.239 04:48, 14 February 2007 (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 function 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;
   }
...

--Cmreigrut 19:42, 23 January 2007 (UTC)

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)

Compatability with talkright

For whatever reason, this extension appears to conflict with the meta:Talkright extension. If you have both installed, and have

$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['user']['talk'] = true;
$wgGroupPermissions['user']['ns100_read'] = true;
$wgGroupPermissions['user']['ns100_edit'] = true;
$wgGroupPermissions['user']['ns100_create'] = true;
$wgGroupPermissions['user']['ns100_move'] = true;

in your LocalSettings.php, users will be unable to actually edit anything in namespace 100. It's also possible that this is simply an effect of blocking user editing in general while permitting it on a given namespace - I haven't tested that.

To correct this, modify the NamespacePermissions.php file as follows: In function wfNamespacePermissions() add

$wgHooks[ 'AlternateEdit' ][] = 'namespaceEdit';

after

$wgHooks[ 'userCan' ][] = 'namespacePermissionsCheckNamespace';

At the end of the file, (just before the ?> line) add:

function namespaceEdit(&$editPage) {
   global $wgOut, $wgUser, $wgRequest, $wgTitle;

   if ((($ns = $wgTitle->getNamespace()) >= 100) && $wgUser->isAllowed("ns{$ns}_edit")) {
       array_push($wgUser->mRights, 'edit');
   }
   return true;
}

--71.224.196.239 04:47, 14 February 2007 (UTC)

The same thing happens with the read permission (global read deny overrides namespace-specific read allow) Any ideas how to overcome this?

There doesn't seem to be an AlternateRead hook...

This extension is being used at an academic institution

I modified this extension slightly:

1. Turned user defaults to false
2. I also have the extension extend the modification of permissions for the following standard namespaces (in function namespacePermissionsCheckNamespace):
   1. MAIN
   2. TALK
   3. PROJECT
   4. MEDIAWIKI

Here are the modifications.

This allows the sysop to overwrite the defaults in some of the standard areas also. It has been up since August 2006 and so far has worked well. The "student" may edit only the course pages (ns >= 100) they are in and the default namespaces not named above (USER, IMAGE, TEMPLATE, HELP, CATAGORY). I have included my LocalSettings.php modifications and I have also written a script which reads in a list of users and adds them to the database with an appropriate group. I welcome comments. Steve Weppner, Eckerd College--198.187.213.50 17:31, 19 February 2007 (UTC)

This has now been updated using MediaWiki 1.12 This discussion page was helpful in taking care of bugs which arose while updating. The older and newer modifications can still be found above --97.102.104.103 06:12, 10 August 2008 (UTC)

Categorization Problem: Pages in restricted namespaces are listed

After using the NamespacePermissions Extension apply Specialpages patches, I still had a small problem. If I categorize the pages within the restricted namespaces, anonymous users can see pages name listed in its category page. I think include/CategoryPage.php should be patched too. Need help in this issue.--Ikhnaton2 06:39, 10 March 2007 (UTC)

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.

How to protect images used in protected namespace?

Provided that you have an amount of pages which you want to have a restricted access for (eg. only users being part of the appropriate user group(s) may see their content): How can you also protect images used on those pages? It is not very odd that the images used for these pages also contain information which you don't like to either show everybody or permit everybody to modify the images. Is there already any solution available? If not, my idea would be to create extra namespaces for images, so there is an image namespace for each (protected) namespace which has the same access rights like the namespaces which uses the images. The problem is that I'm not very versed with the wiki php code. Can anybody help me, so I know where to start?

TODOs would be:

1. modify the upload functionality, so a user can choose to which namespace the image shall be available.
2. modify the functionality which maps wiki code to image url in order to permit using images from different namespaces. In case the image is not from the appropriate image namespace (the one which fits to the namespace where the image is embedded) a symbol/icon shall be displayed which shows that there was an error (e.g. a big lock).

Thanks in advance,

--Sternenfaenger 10:58, 2 October 2007 (UTC)

Patch: Restricted namespaces showing up on SpecialPreferences page, Search tab

I didn't want users w/o the permissions to a particular namespace to be able to set a default search on such a namespace, and indeed, didn't even want them to be able to know about the namespace (inference control). Edit the SpecialPreferences.php code. Replace function namespacesCheckboxes() with this:

 function namespacesCheckboxes() {

                global $wgContLang, $wgUser;

                # Determine namespace checkboxes
                $namespaces = $wgContLang->getNamespaces();
                $r1 = null;

                foreach ( $namespaces as $i => $name ) {
                        if ($i < 0)
                                continue;
                        if ( $i >= NS_MAIN) {
                                $userAllowed = $wgUser->isAllowed("ns{$i}_read");
                                $groupExists = in_array("ns{$name}RO", $wgUser->getAllGroups());
                                if ( $userAllowed || !$groupExists ) {
                                        $checked = $this->mSearchNs[$i] ? "checked='checked'" : '';
                                        $name = str_replace( '_', ' ', $namespaces[$i] );

                                        if ( empty($name) )
                                                $name = wfMsg( 'blanknamespace' );

                                        $r1 .= "<input type='checkbox' value='1' name='wpNs$i' id='wpNs$i' {$checked}/> <label for='wpNs$i'>{$name}</label><br />\n";
                                }
                        }
                }
                return $r1;
        }

-- Dave Greenberg, 03/12/2008 12:03PM CST

Extension doesn't works with MW 1.12.0 - for me

After upgrade to MW 1.12.0 extension stops working. I didn't change settings in LocalSetting.php, I have there something like this:

$wgExtraNamespaces =
  array(
    100 => "DW",                   // dokumentacja wewnętrzna
    101 => "DW_talk",              // dokumentacja wewnętrzna
  );

$wgGroupPermissions['*']['ns100_read'] = false;
$wgGroupPermissions['*']['ns100_edit'] = false;
$wgGroupPermissions['*']['ns100_move'] = false;
$wgGroupPermissions['*']['ns100_create'] = false;
$wgGroupPermissions['*']['ns101_read'] = false;
$wgGroupPermissions['*']['ns101_edit'] = false;
$wgGroupPermissions['*']['ns101_move'] = false;
$wgGroupPermissions['*']['ns101_create'] = false;

...

require_once ('extensions/NamespacePermissions.php');

but everyone can read (only read) pages DW:somepage. Can you tell me what's wrong with this? Thanks in advance.

This is a know bug on 1.12, to resolve it, you can remove lines 1386 to 1388 in includes/Title.php wich are like this:

# Shortcut for public wikis, allows skipping quite a bit of code path 
if ($wgGroupPermissions['*']['read']) 
    return true;

iAlex 13:09, 27 March 2008 (UTC)

I removed these lines to no avail. My problem is below, 1.9 to 1.15 upgrade. i'm not able to edit ANY page. Timneu22 17:51, 15 July 2009 (UTC)

Permissions Error when deleting page

Hi,

I'm trying to delete page that appear under one of my namespaces. After I press "delete" button I get next error: You do not have permission to do that, for the following reason: You are not allowed to execute the action you have requested.

This occurs under sysop account. Other accounts does not see button "delete", but have RW permissions and can change the page. I'm using mediawiki 1.12.0 Thanks for any help.

Alex.

Solution

Hi Alex,

This is very easily solved.

You can add "delete" permissions to the auto-created groups or you can create a custom group in LocalSettings.php if you want to create new custom groups with different rights, but changing your NamespacePermissions.php is probably easiest. Here is what the permissions section of my NamespacePermissions.php looks like:

function namespacePermissionsCreateGroups() {
    global $wgExtraNamespaces, $wgGroupPermissions;
    foreach ( $wgExtraNamespaces as $num => $title ) {
        
/*If your LocalSettings.php file does not allow read access to all pages and you want to restrict access to some namespaces , use the 
following line to create a read only group */
        $wgGroupPermissions[ "ns{$title}RO" ][ "ns{$num}_read" ] = true;
#Editing and creation permissions        
        $wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_edit" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_read" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_create" ] = true;         
#To prevent the "ns_###RW" group from moving pages
        $wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_move" ] = false;
#To allow deletion and moving - keep these separate to have various levels of wiki modification privileges
       $wgGroupPermissions[ "ns{$title}DEL" ][ "ns{$num}_delete" ] = true;
       $wgGroupPermissions[ "ns{$title}MV" ][ "ns{$num}_move" ] = true;
    }
}

--Fungiblename 21:17, 18 July 2008 (UTC)

Alternative solution

Or you could change the namespacePermissionscheckNamespace function for :

 function namespacePermissionsCheckNamespace( $title, $user, $action, $result ) {
	global $wgUser;
     if ( ( $ns = $title->getNamespace() ) >= 100 ) {
	 //sysop can do everything in theses namespaces
	 if( in_array ("sysop", $wgUser->getGroups() ) ) {
	 	return true;
	 }

         if ( ! $user->isAllowed("ns{$ns}_{$action}") ) {
             $result = false;
             return false;
         }
     } 
     return true;
 }

Since that "global autorisation" only applies for namespaces => 100, it *shouldn't* affect any rights outside theses. Darkoneko m'écrire 13:07, 25 July 2008 (UTC)

Compatibility with extension Simple Namespaces

In NamespacePermissions.php I replaced the code:

function namespacePermissionsCreateGroups() {
    global $wgExtraNamespaces, $wgGroupPermissions;
    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;
    }
}

by the code:

 function namespacePermissionsCreateGroups(){
        global $wgExtraNamespaces, $wgGroupPermissions,$wgDBserver,$wgDBuser,$wgDBpassword,$wgDBname;
        $conexao = mysql_connect($wgDBserver, $wgDBuser, $wgDBpassword) or die("Erro conexao!");
        mysql_select_db($wgDBname,$conexao) or die("Erro ao selecionar banco de dados!");
        $query_sql = "select ns_name,ns_id from namespace_names;";
        $resultado = mysql_query($query_sql,$conexao) or die("Erro ao buscar namespaces!");
        while($row = mysql_fetch_assoc($resultado)){
               $title = $row["ns_name"];
               $num = $row["ns_id"];
       	$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;
       }
       mysql_close($conexao);
 }

And now the NamespacePermissions extension works just fine with the extension Simple Namespaces

Special:Lonelypages

Lonelypages don't find lonely pages into namespaces, so in includes/SpecialLonelypages.php I replaced the code:

  return  "SELECT 'Lonelypages'  AS type,
          page_namespace AS namespace,
          page_title     AS title,
          page_title     AS value
          FROM $page
          LEFT JOIN $pagelinks
          ON page_namespace=pl_namespace AND page_title=pl_title
          WHERE pl_namespace IS NULL
          AND page_namespace=".NS_MAIN."
          AND page_is_redirect=0";

By the code (with the extension Simple Namespaces):

          global $wgDBserver,$wgDBuser,$wgDBpassword,$wgDBname;
          $conexao = mysql_connect($wgDBserver, $wgDBuser, $wgDBpassword) or die("Erro conexao!");
          mysql_select_db($wgDBname,$conexao) or die("Erro ao selecionar banco de dados!");
          $query_sql = "select ns_id from namespace_names;";
          $resultado = mysql_query($query_sql,$conexao) or die("Erro ao buscar namespaces!");
          $string_1 = "( page_namespace=\".NS_MAIN.\"";
          $string_2 = "";	
          while($row = mysql_fetch_assoc($resultado)){
                  $aux_row = $row["ns_id"];
                  $string_2 = " or page_namespace=$aux_row".$string_2;		
          }
          $string = $string_1.$string_2.")";
          $string = "SELECT 'Lonelypages' AS type,
                    page_namespace 	AS namespace,
                    page_title 	AS title,
                    page_title 	AS value
                    FROM $page
                    LEFT JOIN $pagelinks
                    ON page_namespace=pl_namespace AND page_title=pl_title
                    WHERE pl_namespace IS NULL
                    AND $string
                    AND page_is_redirect=0";
                    mysql_close($conexao);
          return $string;

Error Message

I get an error message that says: Error: Warning: Invalid argument supplied for foreach() in ..../extensions/NamespacePermissions.php on line 40. Or something like that, part of it is hidden by my logo. I can still use the wiki, although I haven't tried using the extension yet. I got that text from the post above. When I use either of the workarounds above, I get an error message. The first one says: Parse error: parse error in ...\mediawiki\extensions\NamespacePermissions.php on line 81. The second says: Parse error: parse error in G:\Wiki2\mowes_portable\www\mediawiki\extensions\NamespacePermissions.php on line 86. Huh.. that's weird, earlier it said something about an error on line 33. Any help is greatly appreciated! Thanks, Genius101 23:54, 13 February 2009 (UTC)

Incorrect group in error message

• I have transferred my Namespace Permissions definitions from an MW 1.8.2 system where they work fine, but on 1.13.0 the error message when I try to access a namespace to which I don't have access is "The action you have requested is limited to users in one of the groups *, Users." It should say nsARCHRW, nsARCHRO instead of Users. Anyone else seen this and know how to fix it? Thanks in advance.

Andthepharaohs 10:33, 8 May 2009 (UTC)

Issues when moving pages

I'm using mediawiki 1.14.0 and was having issues with moving pages across namespaces.

After a lot of debugging I found issue was that the moving process was checking for permissions with action "move-target".

I resolved it by modifying the namespacePermissionsCreateGroups function to also allow that on RW groups.

function namespacePermissionsCreateGroups() {
  global $wgExtraNamespaces, $wgGroupPermissions;
  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}RW" ][ "ns{$num}_move-target" ] = true;
    $wgGroupPermissions[ "ns{$title}RO" ][ "ns{$num}_read" ] = true;
  }
}

Just in case it's useful to someone else.

Regards, Matías

--TDeeming (talk) 5 July 2012 (UTC)

Thanks for the information Matias...

I was having problems moving files on a MW 1.19.1 and your extra line fixed the problem.

Tim

HELP! Cannot edit any pages after 1.9 - 1.15 upgrade

I don't actually have any ideas at all. Would something have changed?

Here's a snippet of my file...

// Added for Auth extension
$wgGroupPermissions['*']['createaccount']   = false;
$wgGroupPermissions['*']['read']            = false;
$wgGroupPermissions['*']['edit']            = false;

# no one can create accounts except for SYS OP users
# $wgGroupPermissions['*']['createaccount'] = false;

# special pages
$wgGroupPermissions[ '*' ][ 'ns-1_read' ]   = true;
$wgGroupPermissions[ '*' ][ 'ns-1_edit' ]   = true;
$wgGroupPermissions[ '*' ][ 'ns-1_create' ] = true;

# regular pages
$wgGroupPermissions[ '*' ][ 'ns0_read' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns0_edit' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns0_create' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns0_move' ] = true;

# regular talk pages
$wgGroupPermissions[ '*' ][ 'ns1_read' ] = true;
$wgGroupPermissions[ '*' ][ 'ns1_edit' ] = true;
$wgGroupPermissions[ '*' ][ 'ns1_create' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns1_move' ] = true;

# user pages
$wgGroupPermissions[ '*' ][ 'ns2_read' ] = true;
$wgGroupPermissions[ '*' ][ 'ns2_edit' ] = true;
$wgGroupPermissions[ '*' ][ 'ns2_create' ] = true;

# user talk pages
$wgGroupPermissions[ '*' ][ 'ns3_read' ] = true;
$wgGroupPermissions[ '*' ][ 'ns3_edit' ] = true;
$wgGroupPermissions[ '*' ][ 'ns3_create' ] = true;

# wiki pages
$wgGroupPermissions[ '*' ][ 'ns4_read' ] = true;
$wgGroupPermissions[ 'bureaucrat' ][ 'ns4_edit' ] = true;
$wgGroupPermissions[ 'bureaucrat' ][ 'ns4_create' ] = true;

# images
$wgGroupPermissions[ '*' ][ 'ns6_read' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns6_edit' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns6_create' ] = true;

# image talk
$wgGroupPermissions[ '*' ][ 'ns7_read' ] = true;
$wgGroupPermissions[ '*' ][ 'ns7_edit' ] = true;
$wgGroupPermissions[ '*' ][ 'ns7_create' ] = true;

# mediawiki pages
$wgGroupPermissions[ 'bureaucrat' ][ 'ns8_read' ] = true;
$wgGroupPermissions[ 'bureaucrat' ][ 'ns8_edit' ] = true;
$wgGroupPermissions[ 'bureaucrat' ][ 'ns8_create' ] = true;

# templates
$wgGroupPermissions[ '*' ][ 'ns10_read' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns10_edit' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns10_create' ] = true;

# template talk
$wgGroupPermissions[ '*' ][ 'ns11_read' ] = true;
$wgGroupPermissions[ '*' ][ 'ns11_edit' ] = true;
$wgGroupPermissions[ '*' ][ 'ns11_create' ] = true;

# help
$wgGroupPermissions[ '*' ][ 'ns12_read' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns12_edit' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns12_create' ] = true;

# help talk 
$wgGroupPermissions[ '*' ][ 'ns13_read' ] = true;
$wgGroupPermissions[ '*' ][ 'ns13_edit' ] = true;
$wgGroupPermissions[ '*' ][ 'ns13_create' ] = true;

# categories
$wgGroupPermissions[ '*' ][ 'ns14_read' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns14_edit' ] = true;
$wgGroupPermissions[ 'editor' ][ 'ns14_create' ] = true;

# categories talk
$wgGroupPermissions[ '*' ][ 'ns15_read' ] = true;
$wgGroupPermissions[ '*' ][ 'ns15_edit' ] = true;
$wgGroupPermissions[ '*' ][ 'ns15_create' ] = true;

# review
$wgGroupPermissions[ 'reviewer' ][ 'ns100_read' ] = true;
$wgGroupPermissions[ 'reviewer' ][ 'ns100_edit' ] = true;
$wgGroupPermissions[ 'reviewer' ][ 'ns100_create' ] = true;
$wgGroupPermissions[ 'bureaucrat' ][ 'ns100_move' ] = true;

This is a documentation wiki used by my company. Right now, NO ONE can document! Timneu22 12:56, 15 July 2009 (UTC)

Suggestion: don't set up groups by default

The namespacePermissionsCreateGroups() function should not be called in the extension itself, as I suspect most users will not need those groups, but will rather assign the nsX_create, nsX_read, etc. permissions to already existing groups.

Those who actually want the special groups defined by namespacePermissionsCreateGroups() should manually call this function in their LocalSettings.php right after the require('extensions/NamespacePermissions.php') call. --Zas 13:00, 7 September 2010 (UTC)

Can only create Talk

I got 2 Namespaces "Adminonly" and "B1KB"

Adminonly is as the name says only for the sysops. When I create an article B1KB:Test, it takes me to the page: http://fihwiki/mediawiki/index.php?title=B1KB:Blablubb&action=edit&redlink=1 But this is only the "Discussion"-page. The Tab for the page is "Adminonly", link is: http://fihwiki/mediawiki/index.php?title=Adminonly:Blablubb&action=edit&redlink=1 Where could be the problem? Permissions are set: From extensions/Namespacepermissions.php

        $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}RW" ][ "ns{$num}_move-target" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "ns{$num}_delete" ] = true;
        $wgGroupPermissions[ "ns{$title}RO" ][ "ns{$num}_read" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "create" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "read" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "edit" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "minoredit" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "upload" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "reupload" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "move" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "move-subpages" ] = true;
        $wgGroupPermissions[ "ns{$title}RO" ][ "read" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "createtalk" ] = true;
        $wgGroupPermissions[ "ns{$title}RW" ][ "writeapi" ] = true;

From Localsettings.php

        $wgGroupPermissions['sysop' ][ 'ns100_read' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns100_edit' ]  = true;
        $wgGroupPermissions['sysop' ][ 'ns100_create' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns100_delete' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns100_move' ]  = true;
        $wgGroupPermissions['sysop' ][ 'ns100_move-target' ]  = true;
        $wgGroupPermissions['sysop' ][ 'ns101_read' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns101_edit' ]  = true;
        $wgGroupPermissions['sysop' ][ 'ns101_create' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns101_delete' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns101_move' ]  = true;
        $wgGroupPermissions['sysop' ][ 'ns101_move-target' ]  = true;
        $wgGroupPermissions['sysop' ][ 'ns102_read' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns102_edit' ]  = true;
        $wgGroupPermissions['sysop' ][ 'ns102_create' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns102_delete' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns102_move' ]  = true;
        $wgGroupPermissions['sysop' ][ 'ns102_move-target' ]  = true;
        $wgGroupPermissions['sysop' ][ 'ns103_read' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns103_edit' ]  = true;
        $wgGroupPermissions['sysop' ][ 'ns103_create' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns103_delete' ] = true;
        $wgGroupPermissions['sysop' ][ 'ns103_move' ]  = true;
        $wgGroupPermissions['sysop' ][ 'ns103_move-target' ]  = true;

Same problem for me Jimerb (talk) 13:42, 11 September 2012 (UTC)

Using the script with other permissions

Hi,

is it possible to use the script with other permissions like "review" permissions exposed from the extension FlaggedRevs?

Answer

I just found it out by myself, it IS possible, just configure the groups like

 $wgGroupPermissions['qm_approver']['ns500_validate'] = true;
 $wgGroupPermissions['qm_approver']['ns500_review'] = true;
 $wgGroupPermissions['qm_approver']['ns500_autoreview'] = true