Extension talk:AccessControl/Archive 1

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)