Extension talk:Improved Access Control

Works, but breaks block on anonymous access
In LocalSettings.php, I have $wgGroupPermissions['*']['read']           = false; and without this extension that stopped users who weren't logged in from viewing pages. But with improved-access-control extension, anonymous users can view all pages.

Any idea how I can fix this?


 * Yikes, I'll see if I can get a fix out for this within the week. JEisen 13:42, 13 January 2009 (UTC)
 * There's now a new download (1.1.2) which should fix this. It's borderline whether this is a bug in MediaWiki or not, but for now there's a fix in my extension. JEisen 06:52, 25 January 2009 (UTC)

Doesn´t work with Mediawiki 1.13.3 ?

 * I have the problem that everyone can take a look on every page. is it my fault and i missconfigured something or has anyone the same problem ?


 * Now works the restriction. but only sysops have access. the groupmanagement doesn´t work.
 * The wikisearch doesn´t work too if your not a sysop
 * Fatal error: Call to a member function getArticleId on a non-object in /var/www/wiki/extensions/improved-accesscontrol/includes/accessHookSupport.php on line 130


 * I'm testing with 1.13.3 and can't reproduce this problem. Can you give more details on your configuration? Are you using the latest version of the extension (1.1.2)? Is this when using the patch, and with what settings in improved-accesscontrol-options.php? JEisen 13:51, 29 January 2009 (UTC)


 * I did a complete new installation(latest version + Patch)
 * I changed following Settings in ia-options to true: $egUsergroupsRequireAdmin and $egAdminCanReadAll
 * With my Sysop Account i´ve got access to all pages; with my Testaccount which is assigned to the Usergroup "Group1" i´ve got access to pages which should be open to the account. But when i try to get access to a restricted page i get following error message:
 * Fatal error: Call to a member function getArticleId on a non-object in /var/www/wiki/extensions/improved-accesscontrol/includes/accessHookSupport.php on line 120


 * Line 119 // Get the article ID to make sure it exists
 * Line 120 $articleID = $title->getArticleId;


 * if I use $wgTitle instead of $title I´ve got a permission error; Even if the patch isn´t installed or while searching the fatal error appears

Problem with transclusion
My wiki (MoWes Package) is as follows:
 * MediaWiki 	1.13.1
 * PHP 	5.2.6 (apache2handler)
 * MySQL 	5.0.67-community-nt
 * latest Version of Improved-AccessControl


 * My Wiki is in english. I created a page called "Usergroup:Restricted" which contains one user (not a sysop!)
 * I created a test page (:Testseite) which I cannot access using another regular user (ok)
 * I created another page which refers to the restricted one, but is not restricted. To me it seems as if transclusion is not checked at all because I always get the contents of the first test page (which I should not be able to see)

Creating a logfile I get following output: (efIACAccessControlUserCanHook) checking access for Elch71 on 'Testseite2' (efIACUserCanAccess) no access controls on article (efIACReturnResult) Return status is 1. Override is.

After applying the Revisions to editpage.php & specialSearch.php the transclusion is changed to an error message in the article. Is this how the transclusion protection works? - sorry, but it is not quite clear to me As a consequence it means: if the page which contains the transclusion exists before the protected article is created - or - the article is protected after the referring page is created the protected text is shown - right?


 * Transclusion protection is put in on editing only -- with the current design, I can't read access controls on a transcluded page before it's loaded. So what it does instead is prevents someone without permissions to transclude a protected page by replacing it with an error. I'm about to pick this code up again to make sure it works with 1.13.5 and 1.14.0 -- I'll see if there's anything I can do to make that cleaner. JEisen 20:36, 14 March 2009 (UTC)
 * understood - thanks for the quick answer. Also many thanks for creating this tool!!! It's really appreciated K.W. 84.149.248.31 18:55, 15 March 2009 (UTC)

thank you f
hey, great extension it help me a lot. One question: how do you run the patch?

thanks miks

Allow 'logged in user'?
Great improvement over the existing access control extensions, with one small issue. I want to allow anonymous access to some pages (for example, the front page), so I cannot just deny all users in the Mediawiki config. However, I'd like to permit logged in users to view other pages (including a 'how to get more access' page).

With access-control-1.0, it was possible to use any page that contained a bulleted list as a list of users; we used Special:ListUsers for this purpose. You could also use the built-in users group, but that didn't work very well (along with other problems, hence moving away from it).

Is it possible to specify 'any logged in user' in an access control block?

Use MediaWiki group
Use this function in "accessHookSupport.php" function efIACUserCanAccessMediaWikiGroups( &$user, &$accessGroups, $action ){

global $egReadOnlyActionAccess; global $wgUser; $explodedGroups = explode( ',,', $accessGroups ); $userGroups = $wgUser->mGroups; $userName = trim($user->getName);

if(in_array($userName, $explodedGroups)) {               efIACDebugLog("(efIACUserCanAccessPageGroups)"."full access granted "); return true; } if(in_array($userName."(ro)", $explodedGroups) && in_array( $action, $egReadOnlyActionAccess )) {               efIACDebugLog( "(efIACUserCanAccessPageGroups)"."read-only access granted "); return true; }       foreach($userGroups as $usergroup) {               if(in_array($usergroup, $explodedGroups)) {                       efIACDebugLog("(efIACUserCanAccessPageGroups)"."full access granted "); return true; }               else if(in_array($usergroup."(ro)", $explodedGroups) && in_array( $action, $egReadOnlyActionAccess )) {                       efIACDebugLog( "(efIACUserCanAccessPageGroups)"."read-only access granted "); return true; }       }        return false; }

195.241.5.2 07:38, 10 June 2009 (UTC) This patch works as expected on MW 1.14 --Pieter Lexis