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 ? Want (talk) 16:26, 17 January 2014 (UTC)


 * Sorry, but no in all details. In 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 ACL:Developers,ACL:Managers 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 ACL:Managers and Managers 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 and 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)

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: Administrators,IT:Department,Sales(ro)

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 Group1,,Group2 Group1/accesscontrol>

new syntax IT:Group1,IT:Group2 IT:Group1

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?

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:

Testdepartment

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. (talk)

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.