Extension talk:AccessControl/Archive 1

See Additional step required for install at bottom, this appear to work. (talk)

Fatal Error in Version 2.2 AccessControl.php with MediaWiki 1.22

Fatal error: Call to a member function getNativeData() on a non-object in C:\xampp\htdocs\mediawiki\extensions\AccessControl\AccessControl.php on line 143
This is urgent please help me somebody!!!

--217.151.230.148 08:54, 8 March 2014 (UTC)
I have this error too. Version of wiki: 1.22.3.

-- Same problem too.. getNativeData seems is not working here. I changed code with theese 3 lines. It does not work propertly, but is better than a black page. Instead of a Blanck Page, with this modification, it will show a "Page not found" message.

if ( $groupPage->getContent() != NULL ) {
$allowedUsers = $groupPage->getContent()->getNativeData();
}

MW version 1.21 can't use AC 2.1

Yes, after installing AC2.1 on MW 1.21, MW can't work.....just can't show any page. I think this extension need upgrading..

Any NEWS about bugs version 1.21 can't use AC 2.1 ??

Hello, Anybody have some informations about the new plugin version developpment ? Is there any bypass on it ? Thanks inkydjango (talk)

New Version

Hi, I've uploaded a version of AccessControl on pastebin that works in my mediawiki 1.21: http://pastebin.com/ap63Vimx

---

Update:

Your proposed changes were included into main AccessControl repository. Want (talk) 12:59, 4 October 2013 (UTC)

Blank page when searching something

Hi! I'm experiencing an error. When I'm logged as an user with permissions to read a restricted page everything's fine: I can search any word and mediawiki shows me some results; but if I'm logged as a normal user, that is to say, an user without permissions to read a restricted page, and I search something, mediawiki shows me up a blank page (and if I'm not logged in, the page is a normal page but with an error: "[7156da24] 2013-11-26 15:25:50: Fatal exception of type MWException"). I found out that the error is at line 147 of AccessControl.php file and I think the error is at line 140. Changing these lines:

if ( method_exists( 'WikiPage', 'getContent' ) ) {
    $groupPage = new WikiPage( $gt );
    $allowedUsers = $groupPage->getContent()->getNativeData();
}

By these:

if ( method_exists( 'WikiPage', 'getContent' ) ) {
    $groupPage = new WikiPage( $gt );
    var_dump($groupPage->getContent());
    exit();
}

I saw that mediawiki prints NULL, so $groupPage is getting that value. I don't have the necessary knowledge of php nor mediawiki to fix this so, do you have any idea of how to solve this problem?

That's life. About this problem know, but I don't know solution. 8-/ Want (talk) 14:09, 3 December 2013 (UTC)

MW Version 1.22.0 and AC 2.1 - 2.2? - still HTTP500-Error while NoAccess

I just made the update from MW 1.21.3 to 1.22.0 and hoped that the AC2.2 discussed in the changelog.txt brings a change to the HTTP500-error discussed above (Download relative to MW 1.22). ...no change. The AccessContol.php is in this download still V2.1. The HTTP-Error occurs while searching or generally accessing a page where users has no rights -> no access.

I found several workarounds (on this page and in the web) for older MW/AC-version and they doesn´t work with the MW 1.21.3 in my environment or they modify the search-function, but not the direct page access. Is there any workarount for the newer MW/AC versions? Perhaps the AC-version 2.2? Enviroment: IIS7 on Windows 2008R2 Server; MW 1.22.0; AC 2.1; PHP 5.3.8; MySQL 5.5.17;

Thanks Matthias 14:30, 7 January 2014

For this problem is not workaround, because searching is Mediawiki core functionality. Extensions AccessControl is not any invasion into core code. If search engine found a page protected by AccessControl, and user has not access rights to this page, is anonymous from its aspect. For it is redirect do it. Want (talk) 15:04, 7 January 2014 (UTC)

Thanks Want for the quick Answer. Yes, for the search-problem the core functionality is untouched. Question: Is it possible to redirect these NoAccess situations from AC to an NoAccess-wiki-page (the search engine would find and check only the "NoAccess contents" instead of the real page)? This would help preventing an error. I understood the function DoRedirect( $info ) in line 168 to (wish to) do so. Additional a redirect to an "NoAccess-wiki-page" would help to control the NoAccess-situations while the user directly accesses to the page. In my mind these functionality was present in an earlier installation (my old MW 1.07.? with AC V?? - after several updates now MW 1.22.0 with the http500-error). Thanks for help an discussions Matthias 16:29, 8 January 2014

I thank you for a more comprehensive description of the problem. Changed code between version 1.3 to 2.1 cause that functionality the extension was not change, but message is not right. I will try to solve the problem as soon as possible Want (talk) 17:23, 8 January 2014 (UTC)

Problem was fixed in version 2.3 I found and was fixed bug in function fromTemplates() too. This bug, was cause why were ignored tags from embedded pages or templates. Want (talk) 23:28, 9 January 2014 (UTC)

Thanks Want for bugfixing. In my installation (see above) the HTTP500-Error is still there. I tried to check/debug the last days, but I can´t get an step further to some meaningful reasons - or meaningful error message. Do you have any idea how i can give you an debug-message for an additional bugfixing? Maybe something principal in my config. While writing...: maybe because "Testgroup" is not defined in Localsetting.php. I will check with existing groups/user in the AC-tag an post the result. Matthias 16:57, 17 January 2014

Isn't this same problem as #Support_of_Mediwiki_Groups? Want (talk) 16:26, 17 January 2014 (UTC)

Sorry, but no in all details. In #Support_of_Mediwiki_Groups only the search-problem will be discussed by modifying the namespace - as i understood. In my installation i get an http500 error not only by searching. The direct access to the secured page cause this error too (...http://wiki/index.php?title=Test -> Error 500, if the user is not included in the tag by name or group membership). The groups are defined in Localsetting.php and the groupsmember via specalpage "Benutzerrechteverwaltung" - userrightsmanagement direct translated...). As i described above, i've tested if the http500-error is attached to an nonexisting groupname in the tag. I get the error too, while using "sysop" or other existing groups between the AC-tags. If i'm am member of the groups between the AC-tag everything is fine an i get the wiki-page. For testing i installed an new wiki with AC as the only additional extension - with the same error. Is there an possibility to export a debug information while executing the AC-code to get closer to the reason? Matthias 16:44, 22 January 2014

In notes for version >= 2.0 is warning. Was problem with the processing of users from groups of MediaWiki, therefore I removed this possibility. Want (talk) 19:39, 22 January 2014 (UTC)

Blank Edit Page

I've added the AccessControl extension to my private MediaWiki and it works when viewing the page, but when I select "edit" (as a user in the accesscontrol group) I just get a blank page. Can't figure out why. Any ideas?

MediaWiki 1.22.1 AccessControl 2.3

Nevermind. Found out the WYSIWYG editor extension I was using wasn't loading properly. Getting rid of the extension makes it work.

I am sorry. Evidently it is problem WYSIWYG extension, which can not work with the AccessControl tag. I don't use WYSIWIG editation. Want (talk) 09:25, 16 January 2014 (UTC)

Mediawiki 1.22.1 and AccessControl 2.1 not picking up groups, all pages blocked for all users apart from sysop

I have installed this extension with Mediawiki 1.22.1 and have created a list of users in a namespace called ACL, the users are defined in groups

ACL:Managers ACL:Lowerusers ACL:Developers ACL:Operations ACL:Sales

To give an example of one the pages ACL:Managers

• User1
• User2
• User3

Then on the pages that I want to grant access to I have put <accesscontrol>ACL:Developers,ACL:Managers</accesscontrol> however this only brings up the warning

This is a protected page!

It does not provide the list of the allowed users and all accounts are locked out apart from the sysop who can read every page.

I have tried <accesscontrol>ACL:Managers</accesscontrol> and <accesscontrol>Managers</accesscontrol> to try and trouble shoot the issue. I have also tried moving the pages into the ACL namespace to see if it is an issue with crossname spaces but no matter what I try every page is blocked for everyone apart from the sysop

ACL existed as namespaces? If so, it may be a problem here. AccessControl extension use double colon in name of access list, but it can not be in collision with any name existing a namespace. Want (talk) 14:00, 20 January 2014 (UTC)

Thanks Want, you were right I had setup ACL as a namespace rather than a double colon page. Correcting this fixes the access control. As an FYI when you use a namepsace like I did it causes the wiki server to through an HTTP 500 error so you don't even get to see the "No Access" page.Thanks again for responding so quickly and with a fix.

Mediawiki 1.19.12 and AccessControl 2.1 not picking up groups, all pages blocked for all users apart from sysop

Whatever I enter between <accesscontrol> and </accesscontrol> only sysop seems to be the only one to be able to view pages. I created a file Customer:Trusted and entered a few useraccounts here, but that doesn't seem to work, nor the option to use $wgUseMediaWikiGroups = true (or false). Every other user, regardless of if (s)he might view the page is directed to the No_Access-page.

How to solve this?

How to provide a unique URL that will redirect both loged an unloged users to the target page

Our need is to provide an unique URL to users: 1. that will redirect tem to the target page if already loged 2. that will go through the login process then redirect them to the corresponding page if not already loged initially

We are using the following URL to address this need https://wiki.server.com/index.php?title=Special:UserLogin&returnto=TargetPage

Currently, only point 2. above works, but not point 1, and we undestand this URL does not fit our need. When the user is already loged, it stays on the Special:UserLogin page, whitout beeing returned to TargetPage

We can not just use URL https://wiki.server.com/index.php?title=TargetPage because as we deny anonymous users to access the content, going to the above URL when user is not loged will be redirected to https://wiki.server.com/index.php/NS:Deny_anonymous This NS:Deny_anonymous would invite the user to login but then return to NS:Deny_anonymous instead of TargetPage

Any tips to achieve this properly ?

Thanks

[1] Versions MediaWiki 1.23.1 (04feb7f) PHP 5.3.2 MySQL 5.1.73 AccessControlExtension 2.4.0

Mediawiki 1.23

Does this work on v.1.23?

Yes, I installed it today on a third party wiki. Works well. Raymond (talk) 16:35, 8 October 2014 (UTC)

Is something special using Version 2.4 or higher with own Templates in MW 1.23.11 LTS? There is a script timeout, when line 222 in function fromTemplate() calls function allRightTags() for the Templatename. More details are below at Searching_for_another_selected_fix_against_2.5

Update: Maybe a fix for templates with the name of the template in a noinclude area would be helpful to work on v1.23.

AccessControl.php has an undefined variable '$rights'

I'm getting this notice:

Undefined variable: rights in /var/www/html/mediawiki/extensions/AccessControl/AccessControl.php on line 225

Also, it appears that I have no $wgAccessControlRedirect variable set in AccessControl.php.

I checked the Special:Version page and the extension is installed. Any comments on this? I'm working with mediawiki 1.23 on Fedora.

I experienced this issue and resolved it by going the maintenance directory (in my case /var/www/html/wiki/maintenance) and running the update script (in my case by running php -f update.php). Unfortunately I can't say why this resolved the issue in my case. --Cjpluss (talk) 12:04, 15 November 2014 (UTC)

Given up on this extension

I'm not familiar with PHP and I was unable to get this extension to work. After reading the extensions page, I was under the impression that I have to do the following:

Step 1

Create a namespace say IT by adding this to LocalSettings.php:

$wgExtraNamespaces[500] = "IT";

Step 2

create a page "IT:Department"

Step 3

Add this to the content of "IT:Department":

• John Doe
• Jane Doe (ro)

step 4

Create some new page, say "AA", and add this at the beginning:

<accesscontrol>Administrators,IT:Department,Sales(ro)</accesscontrol>

Now AA has permissions controlled by accesscontrol. I've tried this and it doesn't work. Am I doing this correctly? If this is incorrect, then someone needs to edit the page since it's giving bad instructions on how to use the extension.

I agree that the instructions for group creation here are terrible and unclear. I am about to give this extension a try in the next few days. If I figure out how to set up groups, I will update the instructions with something saner. --24.47.169.50 23:29, 23 February 2015 (UTC)

Upgrade from Accesscontrol version 1 to 2.5

We use this extention a long time. We have many articles created with accesscontrol.

Is it possible to make a batch update to migrate all the articles.

old syntax

<accesscontrol>Group1,,Group2</accesscontrol>
<accesscontrol>Group1/accesscontrol>

new syntax

<accesscontrol>IT:Group1,IT:Group2</accesscontrol>
<accesscontrol>IT:Group1</accesscontrol>

Old syntax, as used by your wiki, was used in original Extension:Group Based Access Control. Extension:AccessControl is fork, which this used never. You may used Extension:Improved Access Control, where same syntax is used. -- Want (talk) 17:14, 29 April 2015 (UTC)

Deny on search

I have a problem with the accesscontrol. If I enter a new name in search which isn't in index I get the the option to create a new site. But if this search string (like "foobar") was found in the index everything is ok if no accesscontrol was insert in the content. If one result have the wrong group my browser return this two results after search back:

Userstatus: Logged in user and not logged in user
$wgAccessControlRedirect = true;
Redirect to: index.php5/Wikiseite:Deny_anonymous
Browser: Deny anonymous

Userstatus: Logged in user
$wgAccessControlRedirect = true;
No Redirect
Link: index.php5?title=Special%3ASearch&profile=default&search=Foobar&fulltext=Search
Browser: Fatal error: Call to a member function getNativeData() on a non-object in /mediawiki/extensions/AccessControl/AccessControl.php on line 154

Userstatus: Not logged in user
$wgAccessControlRedirect = true;
No Redirect
Link: index.php5?title=Special%3ASearch&profile=default&search=Foobar&fulltext=Search
Browser: This is a protected page! and then all found items will displayed

Is it a bug or a feature between MW 1.23.5 and AC 2.5? What's the solution?

Version 2.5 uses a variable $wgAccessControlRedirect. If is set value to false, are results search a page with pieces of content from pages where is string found. Is it behaviour, which can be for content of pages a problem. Somebody doesn't take care of it, somebody does problem when unauthorized user sees the content of the page. For it is default value of $wgAccessControlRedirect true (default) - unauthorized user is redirected from a results page to info page. It is only workaround. Not solution. Want (talk) 17:49, 29 April 2015 (UTC)

Additional step required for install

I thought I'd drop in and provide some info on some additional steps I had to perform to get this extension working for me.

Firstly, to resolve the following error:

PHP Notice: Undefined variable: rights in /var/www/html/wiki/extensions/AccessControl/AccessControl.php on line 225

I simply entered the maintenance directory in the wiki install and ran php -f update.php

Secondly, for this error:

PHP Fatal error: Call to a member function getNativeData() on a non-object in /var/www/html/wiki/extensions/AccessControl/AccessControl.php on line 154

I did the following. In extensions/AccessControl/AccessControl.php, the following line (line 151 in my case), I needed to manually specify the ID of the namespace. I figured this out by looking into the makeTitle method in MediaWiki documentation; the first parameter is the namespace ID so I tried manually changing this to the custom namespace I'm using for the access control lists (in my case ID 552 named Authgroups, I defined this as $wgExtraNamespaces[552] = "Authgroups"; in LocalSettings.php). The modification was:

Before: $gt = $Title->makeTitle( 0, $group );

After: $gt = $Title->makeTitle( 552, $group );

Then, if not already done, I create an access control list inside this namespace by browsing to Authgroups:Testdepartment. In here I define a list of users:

• Joebloggs
• JaneSmith

Finally I go to my page I wish to lock down, which is in the default namespace and add the following tag at the top:

<accesscontrol>Testdepartment</accesscontrol>

Note that I omit the namespace from the tag, I believe this works because I've now hardcoded it in the config.

I have no idea why this resolves the issue or why the code is like this, but it worked for me. I hope this helps. --Cjpluss (talk) 12:18, 15 November 2014 (UTC)

This appears to work, would like better fix. (falazar talk)

I did not run into the first issue on a MW 1.23 but into the second one. Patching the file "AccessControl.php" as advised fixes the issue. Thanks a ton and cheers --[[kgh]] (talk) 14:40, 30 April 2015 (UTC)

There is another error in that it appears to clear data at the top of the search results page, you can fiddle with the code near:

       # $wgOut -> clearHTML();  # comment this line, messing up search results header
       $wgOut -> prependHTML( wfMessage( 'accesscontrol-info-box' ) -> text() );

to change this behaviour

Needs opatchers for Mediawiki 1.24

The extension doesn't work with MediaWiki 1.24, it uses too many obsolete functions. See Manual:Title.php and Manual:WikiPage.php for example, to see the latest API's.

The following patch fixes it for me:

 --- a/AccessControl.php
 +++ b/AccessControl.php
 @@ -146,12 +146,16 @@ function getUsersFromPages( $group ) {
         /* Extracts the allowed users from the userspace access list */
         $allowedAccess = Array();
         $allow = Array();
 -       $Title = new Title();
  // Remark: position to add code to use namespace from mediawiki
 -       $gt = $Title->makeTitle( 0, $group );
 +       // $Title = new Title();
 +       // $gt = $Title->makeTitle( 0, $group );
 +       $gt = Title::newFromDBKey( $group );
         if ( method_exists( 'WikiPage', 'getContent' ) ) {
 -               $groupPage = new WikiPage( $gt );
 -               $allowedUsers = $groupPage->getContent()->getNativeData();
 +               # $groupPage = new WikiPage( $gt );
 +               # $allowedUsers = $groupPage->getContent()->getNativeData();
 +               $groupPage = WikiPage::factory( $gt );
 +               $groupContent = $groupPage->getContent( Revision::RAW );
 +               $allowedUsers = ContentHandler::getContentText( $groupContent );
         } else {
                 // create Article and get the content
                 $groupPage = new Article( $gt, 0 );

Note, however, there are other uses of 'new' in the code, these should be replaced by factories as well. Linas (talk) 19:08, 13 December 2014 (UTC)

Why are these changes not being checked into the repository?

Why isn't https://git.wikimedia.org/git/mediawiki/extensions/AccessControl.git being updated with these updates?

Selected fixes against 2.5

Here are some more fixes that we had to make in order to make this extension work:

1. Fix up working with namespaces - the actual version does not work with namespaces, despite documentation
2. There is a problem if usernames can be converted to integer (like user '123456789' - there is an implicit type conversion and the extension will not work on such users.
3. Along the way, we stop using members of the User class directly and switched to accessors and other functions - it is cleaner.

diff -r b6290ac5c613 -r 19ac5b8e84d8 AccessControl/AccessControl.php
--- a/AccessControl/AccessControl.php	Thu Mar 19 11:28:33 2015 +0100
+++ b/AccessControl/AccessControl.php	Thu Mar 26 10:00:51 2015 +0100
@@ -92,10 +92,10 @@
   foreach ( array_keys( $users ) as $user ) {
     switch ( $users[$user] ) {
       case 'read':
-        $usersreadonly[] = $user;
+        $usersreadonly[] = (string)$user;
         break;
       case 'edit':
-        $userswrite[] = $user;
+        $userswrite[] = (string)$user;
         break;
     }
   }
@@ -147,8 +147,8 @@
   $allowedAccess = Array();
   $allow = Array();
   $Title = new Title();
-// Remark: position to add code to use namespace from mediawiki
-  $gt = $Title->makeTitle( 0, $group );
+
+  $gt = $Title->newFromText( $group );
   if ( method_exists( 'WikiPage', 'getContent' ) ) {
     $groupPage = new WikiPage( $gt );
     $allowedUsers = $groupPage->getContent()->getNativeData();
@@ -229,12 +229,12 @@
       }
       if ( isset( $rights ) ) {
         if ( is_array( $rights ) ) {
-          if ( $wgUser->mId === 0 ) {
+          if ( $wgUser->isAnon() ) {
             /* Redirection unknown users */
             $wgActions['view'] = false;
             doRedirect('accesscontrol-move-anonymous');
           } else {
-            if ( in_array( 'sysop', $wgUser->mGroups, true ) ) {
+            if ( in_array( 'sysop', $wgUser->getGroups(), true ) ) {
               if ( isset( $wgAdminCanReadAll ) ) {
                 if ( $wgAdminCanReadAll ) {
                   return true;
@@ -242,7 +242,7 @@
               }
             }
             $users = accessControl( $rights['groups'] );
-            if ( ! in_array( $wgUser->mName, $users[0], true ) ) {
+            if ( ! in_array( $wgUser->getName(), $users[0], true ) ) {
               $wgActions['edit']           = false;
               $wgActions['history']        = false;
               $wgActions['submit']         = false;
@@ -253,7 +253,7 @@
               $wgActions['revisiondelete'] = false;
               $wgActions['rollback']       = false;
               $wgActions['markpatrolled']  = false;
-              if ( ! in_array( $wgUser->mName, $users[1], true ) ) {
+              if ( ! in_array( $wgUser->getName(), $users[1], true ) ) {
                 $wgActions['view']   = false;
                 return doRedirect( 'accesscontrol-move-users' );
               }
@@ -320,7 +320,7 @@
 function hookUserCan( &$title, &$wgUser, $action, &$result ) {
   /* Main function control access for all users */
   global $wgActions, $wgAdminCanReadAll;
-  if ( $wgUser->mId === 0 ) {
+  if ( $wgUser->isAnon() ) {
     /* Deny actions for all anonymous */
     $wgActions['edit']           = false;
     $wgActions['history']        = false;
@@ -336,7 +336,7 @@
 
   $rights = allRightTags( getContentPage( $title->getNamespace(), $title->mDbkeyform ) );
   if ( is_array( $rights ) ) {
-    if ( $wgUser->mId === 0 ) {
+    if ( $wgUser->isAnon() ) {
       /* Redirection unknown users */
       $wgActions['view'] = false;
       doRedirect( 'accesscontrol-redirect-anonymous' );
@@ -349,7 +349,7 @@
         }
       }
       $users = accessControl( $rights['groups'] );
-      if ( in_array( $wgUser->mName, $users[0], true ) ) {
+      if ( in_array( $wgUser->getName(), $users[0], true ) ) {
         return true;
       } else {
         $wgActions['edit']           = false;
@@ -362,7 +362,7 @@
         $wgActions['revisiondelete'] = false;
         $wgActions['rollback']       = false;
         $wgActions['markpatrolled']  = false;
-        if ( in_array( $wgUser->mName, $users[1], true ) ) {
+        if ( in_array( $wgUser->getName(), $users[1], true ) ) {
           return true;
         } else {
           $wgActions['view']   = false;

Searching for another selected fix against 2.5

The "selected fixes against 2.5" helped a lot. Thank you very much!

But there also seems to be a problem with noinclude areas in templates (see "Update" below) after upgrading from MW 1.16 with accesscontrol v1.1 to MW 1.23.11 LTS with AccessControl >=2.5 with own templates and function fromTemplates() in line 222 and a timeout:

$rights = allRightTags( getContentPage( 10, $templatename ) );

It seems the function calls another function allRightTags() which calls again fromTemplates() calling again allRightTags() and so on with the following content, where Ynotice is the name of a template:

{{Ynotice|text=...}}

The following code changes in AccessControl.php seem to stop the endless function calls after a few rounds, but do not work with extension ApprovedRevs:

// new variable added in line 43
$template_check = NULL;

// function fromTemplates
// extending line 199 with new variable
global $wgUser, $wgAdminCanReadAll, $template_check;
// condition for new variable and line 222
if($template_check !== $templatename){
  $template_check = $templatename;
  $rights = allRightTags( getContentPage( 10, $templatename ) );
}

// function allRightTags
// new in line 274 for new variable
global $template_check;
// condition for line 290
if( (!empty($template_check) && $template_check!==$string) || empty($template_check)){
  fromTemplates( $string );
}

After testing with some text outputs the order of the used functions seems to be

• hookUserCan() calling:
• allRightTags() starting 1st time and calling:
• fromTemplates() calling:
• allRightTags() starting 2nd time and ending with no session redirect
• allRightTags() ending 1st time with no session redirect
• hookUserCan() starts again calling allRightTags() starting 1st time and calling fromTemplates()

Versions before and after Upgrading:
The upgrade was done with a new installation by copying the image-directory of the wiki and importing the dump of the sql-database. AccessControl was added as version 2.5 (REL1_26). I found no download version 2.5 REL1_23. The offered download for MW v1.23 was AccessControl-REL1_23-befc02e.tar.gz with v2.4, although v2.5 is recommended since MW v1.21. For Version 2.5 I had to download REL1_24 or higher versions.

Update: The problem is caused by a noinclude area in a template, when the name of the template is repeated. For example, if there is a template "Ynotice" there must not be a text "Ynotice|" in the noinclude area, but &#89; can be used instead of Y:

<noinclude>
== Kopiervorlage ==
<pre>
{{Ynotice|text=
}}
</pre>
</noinclude>

How can the problems with timeout caused by templates with noinclude areas and with download versions get fixed?

can not work properly with Extension:LDAP_Authentication

I use Extension:LDAP_Authentication in MediaWiki and I found AccessControl can not work properly with it . It writes : Fatal error: Call to a member function getNativeData() on null in /opt/lampp/htdocs/w/extensions/AccessControl/AccessControl.php on line 158 . Can this problem be fix up ? --Willemzhai (talk) 08:05, 13 April 2015 (UTC)

If the group does not exist

Contributions by automatic translation

<accesscontrol> </accesscontrol>

<accesscontrol> Group: </accesscontrol>

Group will result in an error in does not exist case . So hard to notice , I hope modifications as return a message such as " There is no group." . I'm sorry because there is no skill to write the appropriate patch .

For this case is necessary set a variable $wgAdminCanReadAll on true, but you are right, I must it repaired. Want (talk) 08:07, 7 July 2015 (UTC)

Thank first . I'm waiting in the hope that be fixed .Runequest77 (talk) 13:42, 11 July 2015 (UTC)

Search function stops working and get access denied when not logged in

MediaWiki 1.23.8 Semantic MediaWiki 2.1.1

I downloaded the latest AccessControl a user is not logged in and tries to search for anything that is not a page name gets access denied. or if a regular logged in user tries to search for anything that is not a page name they just get a blank page.

Is there a way to fix this I'm using SMW search

It is potential risk, because it may allow get critical informations from protected content over searching. Want (talk) 16:35, 8 July 2015 (UTC)

can't redirect from restricted page

Hello. I have a MediaWiki 1.25.2 PHP 5.3.3 MySQL 5.5.46

and .. i don't understood how i can made a redirect. In config file i put "true" in $wgAccessControlRedirect, but WHERE is i must put the adrees page for redirect? help me please.

Ivan.

Undefined variable: rights / Fatal error: Call to a member function getNativeData()

Hello,

im getting following PHP errors after installing AccessControl on MediaWiki 1.23 on RHEL 6:

Notice: Undefined variable: rights in /var/www/html/mediawiki-1.23.8/extensions/AccessControl/AccessControl.php on line 228

                    if ( is_array( $rights ) ) {
                        if ( $wgUser->mId === 0 ) {
                            /* Redirection unknown users */
                            $wgActions['view'] = false;
                            doRedirect('accesscontrol-move-anonymous');
                            } else {
                                if ( in_array( 'sysop', $wgUser->mGroups, true ) ) {
                                        if ( isset( $wgAdminCanReadAll ) ) {
                                                if ( $wgAdminCanReadAll ) {
                                                        return true;
                                                        }

Fatal error: Call to a member function getNativeData() on a non-object in /var/www/html/mediawiki-1.23.8/extensions/AccessControl/AccessControl.php on line 152

$allowedUsers = $groupPage->getContent()->getNativeData();

This is how my LocalSettings.php looks like:

require_once "$IP/extensions/AccessControl/AccessControl.php";
// Define constants for my additional namespaces.
define("NS_ACL", 7000); // This MUST be even.
define("NS_ACL_TALK", 7001); // This MUST be the following odd integer.

// Add namespaces.
$wgExtraNamespaces[NS_ACL] = "ACL";
$wgExtraNamespaces[NS_ACL_TALK] = "ACL_talk"; // Note underscores in the namespace name.

I added also a Page called "ACL:Test" including "*testuser". When I hit the restricted page with my administrator account everything works fine but when I hit it with the "testuser" account I get php errors. The top of the page looks like this:

<accesscontrol>Administrators,ACL:Managers</accesscontrol>

I already tried to run maintaince scripts but it didn't helped..

Is there any way to fix this?

I am having problems here too after upgrading to Mediawiki 1.27 and the 1.27 snapshot of Access Control. The first problem was an autonomous user visiting any history page would see only "deny_action". The error was "PHP Fatal error: Call to a member function getNativeData() on null in /home/public_html/live/public/extensions/AccessControl/AccessControl.hooks.php on line 122". That issue was resolved by turning off file cache. However, when an anonymous user visits a restricted page the server returns a http error 500. On mediawiki 1.26.3 which I used before, none of these problems existed.

Here is line 122 of the above script: $allowedUsers = $groupPage->getContent()->getNativeData();

T0lk (talk) 20:23, 28 July 2016 (UTC)

The solution was to follow a step from above about hardcoding the namespace. However, you can no longer use built-in groups to control access to pages. T0lk (talk) 00:36, 29 July 2016 (UTC)

Upgrade to MW 1.23 AC 2.5 with wiki database instead of group page with members

After upgrading from MW 1.16 with AccessControl 1.1 to MW 1.23 LTS with AccessControl v2.5 REL1_26 (REL1.23 was not AC v2.5 but v2.4 with changelog.txt only to v2.3 and caused several errors) there was the problem that "AccessControl" searches for a page with the name of a group, for example "groupname", to find group members, but causes problems because a page "Groupname" with normal content already exists.

Using a page "groupname" after upgrading also could mean to add a lot accounts to that page manually - an uncomfortable way if the group could be used from the wiki database.

The solution could be to modify the function "makeGroupArray(...)" and configure "LocalSettings.php" with "$wgUseMediaWikiGroups". In function "makeGroupArray(...)" some code should be added between line 89 and line 90 (described below).

LocalSettings.php

require_once("$IP/extensions/AccessControl/AccessControl.php");
$wgUseMediaWikiGroups = true;

AccessControl.php with group from wiki database

function makeGroupArray( $accesslist ) {
  ...
  $userswrite = Array();
  $usersreadonly = Array();
  // added: users of group from wiki database
  global $wgUseMediaWikiGroups, $wgUser;
  if($wgUseMediaWikiGroups === true){
    if( in_array($accesslist,$wgUser->getGroups()) ){
      $userswrite[] = $wgUser->getName();
    }
    return array( $userswrite, $usersreadonly );
  }
  // users from group-page with list of users and their rights for writing or reading
  $users = getUsersFromPages( $accesslist );
  ...

Some other changes in file "AccessControl.php" could be helpful:

• Changes as described at #Selected_fixes_against_2.5
  • Replace "if( $wgUser->mId === 0 )" with "if( $wgUser->isAnon() )"
  • Replace "$wgUser->mGroups" with "$wgUser->getGroups()"
  • Replace "$wgUser->mName" with "$wgUser->getName()"
  • In function "makeGroupArray(...)" at the switch cases edit and write "(string)$user should be used instead of "$user"
• In functions "getUsersFromPages(...)" and "allRightTags(...)" the method "makeTitle( 0, [$group|$redirecttarget] ) could be replaced by the method newFromText( [$group|$redirecttarget] )
• To prevent php notices for disallowed value NULL modify the functions "getTemplatePage(...)" and "getUsersFromPages(...)" at "$contentPage->getContent()->getNativeData();"
• In some cases maybe the right "Revision::RAW" could be needed and should be added - on your own risk: $contentPage->getContent( Revision::RAW )

Changes in "getTemplatePage( $template )" to prevent handling with NULL similar to function "getContentPage(...)":

 if ( method_exists( 'WikiPage', 'getContent' ) ) {
  ...
  // changed: prevent handling with NULL
  #$contentPage = new WikiPage( $gt );
  #return $contentPage->getContent()->getNativeData();
  $contentPage = WikiPage::factory( $gt );
  $contentPageContent = $contentPage->getContent(); /* Revision::RAW */
  if($contentPageContent != NULL){
    return ContentHandler::getContentText( $contentPageContent );
  }
 } else {
  // create Article and get the content
  ...
 }

Changes in "getUsersFromPages( $group )" to prevent handling with NULL similar to function "getTemplatePage(...)":

 if ( method_exists( 'WikiPage', 'getContent' ) ) {
  ...
  // changed: prevent handling with NULL
  #$groupPage = new WikiPage( $gt );
  #$allowedUsers = $groupPage->getContent()->getNativeData();
  $groupPage = WikiPage::factory( $gt );
  $groupContent = $groupPage->getContent(); /* Revision::RAW */
  if($groupContent != NULL){
    $allowedUsers = ContentHandler::getContentText( $groupContent );
  }
 } else {
  // create Article and get the content
  ...
 }

Visual Editor for <accesscontrol>Group</accesscontrol>

Does anyone know of a visual editor for editing the groups within <accesscontrol></accesscontrol>

Maybe build one within the WikiEditor javascript?

AccessControl not working with VisualEditor?

I installed MediaWiki 1.27 and AccessControl 2.6.

It working fine in Wiki text mode. But user can still edit protected article when changing to VisualEditor mode.

Is it my setup error? Or a known issue already? Is there any solution now? --Harry0725 (talk) 08:22, 4 August 2016 (UTC)

Correction: From test result, I found following situation:

Example:

GroupA(ro) is set as readonly group in TestPage. (GroupB is NOT)

Member of GroupA can read TestPage / NOT able to edit by WikiEditor / BUT writable by VisualEditor

Member of GroupB canNOT read or write TestPage, no matter by WikiEditor or VisualEditor.

Please help if anyone knows what's happening, thanks! --Harry0725 (talk) 08:22, 4 August 2016 (UTC)

I do not believe that this extension supports the VisualEditor and I doubt there will ever do so. I am actually happy that it works the way it currently does. Still, one never knows... --[[kgh]] (talk) 08:29, 4 August 2016 (UTC)

In current, it's ok for me to use this extension. I just want to make sure only authorized group members can access specific pages. Usually, they will be able to r/w it. According to above test result, unauthorized group members cannot edit article either by VE or Wiki. It's enough for me.

However, still hope there be a great support for both editors in future update. --JHK (talk) 09:00, 4 August 2016 (UTC)