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

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.