Extension talk:PermissionACL

MediaWiki 1.13 Upgrade

Has anybody else had trouble with this extension after upgrading to MediaWiki 1.13? I upgraded from 1.12 and now "Special" pages that used to be public are restricted. I found that some problems were case sensitivity issues (e.g., if I had white-listed "Special:userlogin", I had to change that to "Special:UserLogin". But for some reason the "Create Account" page cannot be white-listed. It is the same page as the login page ("Special:UserLogin" with just an additional URL parameter). The login page is accessible but the create account page is not. If I disable PermissionACL, then the create account page is accessible again. Any ideas? This is the line I currently have in my LocalSettings.php file.

$wgWhitelistRead = array('Special:UserLogin', 'Special:UserLogout', 'Special:ResetPass', 'Special:ConfirmEmail');

I could fix this by allowing namespace NS_SPECIAL for user '*'. Userlogin can then be done but it is a workaround, afterall. --Herzrein 08:12, 6 October 2009 (UTC)

  if (($title->getSubpageUrlForm()=='UserLogin') && ($user->isAllowed('createaccount')))
    return TRUE;

Insert above two lines into the function "PermissionACL_isRuleApplicable" of the file "PermissionACL.php". Just add it at the beginning of this function, the program will check the user's permission and then run permissionacl. if this user is able to createaccount, then he can do it. --Yingsen 03:21, 5 May 2010

Insert a permission for the action createaccount into your LocalSettings.php. This should do the trick without changing the code.

e.g.

$wgPermissionACL[] = array('group'     => '*',
			   'page'      => '*',
			   'action'    => 'createaccount',
			   'operation' => 'permit');

11:45, 20 October 2010 (UTC)91.33.20.64

Above solutions aren't working on MediaWiki 1.21 (at least for me). Next workarround does

$wgPermissionACL[] = array('group'     => '*',
                           'page'      => 'Special:Userlogin',
                           'action'    => '*',
                           'operation' => 'permit');

Note: 'page' value should be "Especial:Entrar" if mediawiki is configured in Spanish.

Upload Files

While uploading file, it shows "Upload warning , Protected page". Superusers do not get this error. If PermissionACL is disabled, no error too. Any idea? - Hugh

I'm having a similar problem uploading files. With PermissionACL enabled, the only users that can upload files are those in the $wgPermissionACL_Superuser array. Any other user, even one that is in the Sysop group is unable to upload files. It's not a problem with getting to the Special:Upload page. All registered users are able to go to the upload page, specify (pick) a file, and click on the "Upload file" button. Once the "Upload file" button is pressed, the page displays:

  Permission Errors
  ------------------------
  You do not have permission to do that, for the following reason:

  You are not allowed to execute the action you have requested.

With PermissionACL disabled, any registered user can successfully upload a file.

Has anyone been able to configure PermissionACL to allow non-superuser accounts to upload files? Does anyone know of any other sites, forums, etc. for discussing this extension? This was one of the very few sites I could find, and so far I haven't found a solution to this problem.

- Rowdy. 1/16/09.

Upload Files (one solution)

If you're using the PermissionACL extension, and want to give non-superusers the ability to upload files, here is one method that works. You need to give read/write permissions to the NS_IMAGE namespace, to the group that is allowed to upload files. Add the following rule to your LocalSettings.php file, along with the other rules you created for the PermissionACL extension:

$wgPermissionACL[] = array('group'     => 'UploadGroup',
                           'namespace' => 6,
                           'action'    => '*',
                           'operation' => 'permit');

Notes:

• In the example rule above, "UploadGroup" can be any group that should be allowed to upload files. You can create a custom group that is allowed to upload files, or you can give upload permissions to a preexisting group. For the purposes of my company's wiki, we wanted all registered users to be allowed to upload files. In my LocalSettings.php file, "UploadGroup" was actually the seeded "user" group.
• The default namespaces are defined in the "/includes/Defines.php" file. You would think that you should be able to use the namespace alias (NS_IMAGE) in the 'namespace' clause instead of using the actual integer value (6). However that did NOT work, and I was forced to use the index value instead.
• If the definition of the default namespaces ever changes, this workaround will break. In fact this whole solution is probably a huge security hole, but if you absolutely need to give non-superusers the ability to upload files, then this works.

- Rowdy. 1/19/09.

How can I connect a page to a group?

Please can you tell me what I have to put on the page itself to connect that pages to a difined group?

Answer: All your settings go in your main LocalSetting.php, not individual pages. If you don't want to specify each and every page in this file (totally impractical), you can group your pages in namespaces and specify permissions for each namespace.

Can't see uploaded images

I can see thumbnails in pages but when i try to go to the image's page it says im not allowed, should i give read permission to the image namespace? even if I define the user as $wgPermissionACL_Superuser he is not able to read images. thanks

Protect Semantic Properties

Is there a way to use PermissionACL to define access rights for semantic properties? I'd like to protect some sensitive data that currently can be retrieved by any user simply "asking" the right questions... --Planetenxin 12:56, 14 October 2008 (UTC)

After editing a page I get a blank page

Please can you help me. I would be welcome to implement your Extension, but it doesn't operate.

Problem: After I edit a page, I get a blank page. The result of the changed page isn't displayed. When I disable your Extension then it's very well and I will be redirected to the page I changed actually.

This although I'm superuser in $wgPermissionACL_Superuser.

Mediawiki Release: 1.15.0

Apache: 2.2.11

PHP: 5.2.8

MySQL: 5.0.51a

Many thanks Timotheus.elias 13:01, 13 July 2009 (UTC)

Solution: I'd a blank line at the end of the file PermissionACL.php Timotheus.elias 07:25, 14 July 2009 (UTC)

Compatibility with MW 1.16

I am trying to use this extension with MediaWiki 1.16.0beta3, but, on every page I get 6 overlaid error messages with the following text:

Warning: Cannot modify header information - headers already sent by (output started
at /home/content/c/o/n/mysite/html/vw/extensions/PermissionACL/PermissionACL.php:182) 
in /home/content/c/o/n/mysite/html/vw/includes/WebResponse.php on line 16

76.10.150.183 19:09, 12 July 2010 (UTC)

Turns out that this happened, because there were a few too many spaces after the PHP closing tag (which probably got copied from the code section by accident).

Internal-Section

I'd like to create a namespace like "Intern" which is viewable for all members only and is editable for special users in a special group "intern-edit". I got some problems by giving the right to an read-only member. I've found a solution which i'd like to present now:

#add configuration parameters here
define("NS_INTERN", 110);
$wgExtraNamespaces[NS_INTERN] = "Intern"; //$wgExtraNamespaces = array( 110 => "Intern" );
$wgNamespaceProtection[NS_INTERN]      = array( 'intern-permitted' );
$wgGroupPermissions['intern-edit']['read'] = true;
$wgGroupPermissions['intern-edit']['edit'] = true;
$wgGroupPermissions['intern-edit']['intern-permitted'] = true;
#setup user rights here
$wgPermissionACL_Superuser = array('wikisysop','Ben');
$wgPermissionACL[] = array('namespace' =>  NS_MAIN,
                           'group'     => '*',
                           'action'    => 'read',
                           'operation' => 'permit');
$wgPermissionACL[] = array('namespace' =>  array(NS_MAIN, NS_USER, NS_CATEGORY, NS_INTERN),
                           'group'     =>  array('user','bureaucrat'),
                           'action'    => 'read',
                           'operation' => 'permit');
$wgPermissionACL[] = array('namespace' =>  array(NS_SPECIAL),
                           'group'     =>  array('bureaucrat'),
                           'action'    => 'read',
                           'operation' => 'permit');
$wgPermissionACL[] = array('namespace' =>  array(NS_MAIN, NS_USER, NS_CATEGORY),
                           'group'     =>  array('bureaucrat'),
                           'action'    => 'edit',
                           'operation' => 'permit');
$wgPermissionACL[] = array('namespace' =>  array(NS_INTERN),
                           'group'     => 'intern-edit',
                           'action'    => 'edit',
                           'operation' => 'permit');

$wgGroupPermissions['*']['read']		 = true;
...
$wgGroupPermissions['user']['read']		 = true;
...
$wgGroupPermissions['bureaucrat']['edit']	 = true;
$wgGroupPermissions['bureaucrat']['read']	 = true;
//$wgGroupPermissions['bureaucrat']['intern-permitted']	 = true;

I defined all users ('*') as read-only for all NS_MAIN pages. All members ('user') are allowed to read NS_MAIN and NS_INTERN. Bureaucrats are allowed to edit pages of NS_MAIN and to read NS_SPECIAL. The special group 'intern-edit' is allowed to read all pages including NS_INTERN and to edit NS_INTERN pages only.

I hope it is helpful.

Ben 13:57, 23 May 2011 (MEST)

breaks renaming of pages

… renaming / moving pages doesn't work anymore after using this extension, even with fairly liberal acls:

require_once("$IP/extensions/PermissionACL/PermissionACL.php");
$wgPermissionACL[] = array('group' => '*', 'page' => '*', 'action' => 'edit', 'operation' => 'permit');
$wgPermissionACL[] = array('group' => '*', 'page' => '*', 'action' => 'move', 'operation' => 'permit');
$wgPermissionACL[] = array('group' => '*', 'page' => '*', 'action' => 'create', 'operation' => 'permit');
$wgPermissionACL[] = array('group' => '*', 'page' => '*', 'action' => 'delete', 'operation' => 'permit');

when disabling the extension, everything works fine again.

Private Wiki with Special:ConfirmEmail

I would be pleased if there is someone out there who can solve me little problem. I ´ve got a private wiki which has several WhiteList Artictles. User should register and confirm their Email. Anonymous and registered Users do not have any rights. Here is where the problem goes: When a just registered user tries to confirm his email. He is not allowed to because he has less rights. How can the ACL be help to solve this problem?

Thanks!

PermissionACL not installing properly?

Hi there I've followed the install instructions and up to the point of editing the LocalSettings.php file. Just to test it I've put in: require_once("$IP/extensions/PermissionACL/PermissionACL.php"); but my wiki ends up with a blank screen. If I comment out this line it's fine. Do you have any ideas as to what I'm doing wrong or if there are any preset settings that I need to disable?

I've got the same problem. To solve it change lines 69 and 70, from:

PermissionACL_userCan($title, $user, 'create', &$result) ||
PermissionACL_userCan($title, $user, 'createpage', &$result)

to (without & in $result parameter):

PermissionACL_userCan($title, $user, 'create', $result) ||
PermissionACL_userCan($title, $user, 'createpage', $result)

Add Special pages with subpage to Whitelist

Hi there,

how can I add a Special page with subpage to a Whitelist?

e.g.:
Special:Contributions/Users

Are there delimiters which I can use?

like !^ $! .*$

--Zerano8 (talk) 08:13, 5 May 2015 (UTC)

Permissions by category and page

Hello! i have a problem restricting access to specific categories and pages, the rules i apply don't seem to work, however when i use namespaces it works. I tried adding and removing the permit for NS_CATEGORY in the user group, however when i add rules for a specific category it doesn't seem to work at all (same for pages). Does anyone know what i did wrong? Here is what i have :

$wgPermissionACL[] = array('group' => 'user',
                           'namespace' =>  array(NS_MAIN, NS_SPECIAL, NS_USER, NS_CATEGORY),
                           'action'    => 'read',
                           'operation' => 'permit');

$wgPermissionACL[] = array('group' => 'groupe1',
                           'namespace' =>  array(NS_FOO),
                           'action'    => 'read',
                           'operation' => 'deny');

$wgPermissionACL[] = array('group' => 'groupe1',
                           'page'      => 'PageTest1',
                           'action'    => '*',
                           'operation' => 'deny');

$wgPermissionACL[] = array('group' => 'groupe1',
                           'category'      => 'CatTest1',
                           'action'    => '*',
                           'operation' => 'deny');

---

Hello Guys,

I have the same problem, but depends on the size of your wiki, its not a real problem... You can use one array to storage the value of more than one page, and then it's apply the "action" to all pages in array. You can check the syntax below:

$wgPermissionACL[] = array('group' => 'Sales',
                           'page'      => array('CatTest1','CatTest2','CatTest3','CatTest4','CatTest5','CatTest6'),
                           'action'    => '*',
                           'operation' => 'permit' );

y

About deny options, i seem that deny option only works if you have "deny" before "permit" rules. By this way, i need to deny all pages and namespaces before permit the access to a specifical pages and namespaces

By: Aldair Lucena

Mislabeled Extension?

The extension page says

"This extension stores its source code on a wiki page."

I believe that's incorrect. The code is stored in a .php file, in the extensions directory.