Extension talk:Group Based Access Control

I've followed the instructions, created groups, and applied a policy to a page.. but when I try to edit the page once I've put the accesscontrol tags into it, it refeshes me back to the index page. I have to disable the extention to be able to edit the page again. -Dan (dan@atensyndicate.com)

Warning: Full text of new or changed pages easily accessed
Having figured out that I needed to turn off the caching to make this work, I was all gung-ho, until I realized (and have tested): Any user subscribed to the Special:Newpages or Special:Recentchanges Atom (and I'd guess RSS, although I haven't feed gets pages whether or not they've had access control turned on. So this doesn't work unless you disable RSS and Atom.

I guess it's a good thing I didn't start putting the really private stuff in my wiki-journal...

--DanLyke 22:02, 15 November 2006 (UTC)

Is there any possibility to intercept the search without patching the core code? Are there any hooks etc. I could use? --magicmonty 13:20, 12 January 2007 (UTC)

Group Access Control on 1.8.2
I've attempted to implement your extension in version 1.8.2, with limited success. So far, if a user who is NOT in one of the groups specified on a page by the accesscontrol tag attempts to read the restricted page, he is able to. However, once the user clicks the Edit tab, they are presented with the No_Access page for the article.

I have disabled page cacheing and I'm still getting the same behavior. I've also cleared browser cache. This works flawlessly in 1.7.1

Johann 13:41, 31 October 2006 (UTC)


 * An update to this. I've since completely reinstalled Mediawiki due to an extension that went bad, and it seems to be working fine now. The Groupwikibase code seemed to be causing some issues with several extensions. Between the accesscontrol extension, and a couple of custom functions, I was able to do everything that I wanted to, security-wise.


 * 65.221.183.120 13:57, 3 November 2006 (UTC)


 * I have a very similar problem on mediawiki 1.8.2: Right after logging in and visiting the page that the logged-in user should not have access to, I correctly get the No_Access page. But after pressing the back button and re-clicking the link to the forbidden page, it suddenly just gets displayed to me on this second try!


 * Aha! Updating my previous comment in this space, I explicitly disabled caching with:

$wgMainCacheType = CACHE_NONE; $wgMessageCacheType = CACHE_NONE; $wgParserCacheType = CACHE_NONE; $wgCachePages = false;


 * Right above my inclusion of the access control extensions in my LocalSettings.php and it appears to be working consistently now. I'm not sure I'm ready to sacrifice caching for access control, and this may or may not solve Johann's problem above because he says he disabled caching, but it's worth a try!


 * --DanLyke 18:37, 15 November 2006 (UTC)

Feature request
I might have a go at the first, but I don't really know PHP very well and I doubt I'll get the second feature anywhere... 141.83.61.65 16:48, 3 November 2006 (UTC) IT-Department,Management Sales,,Purchasing
 * Multiple -tags : Also, I noticed that it is not possible to have more than one set of -tags on any single page. This would be helpful to use in templates/categories...
 * Use of template placeholders within the tags : This doesn't work because it seems like the access rights are checked for a template before its text is inserted into another article..
 * Enable access for another groups, example:


 * Add the possibility to set another group in place of sysops to manage page group definition (because sysops have more rights that are not compatible (in term of security) with this feature.

Restrict Message
It may be helpful for newer users if the accesscontrolSettings.php file had a value for the message text. Since it is German by default, some may want to change it.

Awesome Extn!!

Thanks, was fixed in version 0.6

magicmonty 18:00, 30 November 2006 (UTC)

Group Display bugfix
There was a little bug in the accesscontrol.php file, which prevented the list of allowed groups being displayed properly:

If you have multiple groups in your -tag and their names aren't all being displayed: Diese Seite ist nur für die Gruppen Test8 zugänglich!!! instead of seeing something of the pattern: Diese Seite ist nur für die Gruppen Test1, Test4, Test8 zugänglich!!!

Then you need to make a little correction to the accesscontrol.php file after line 128: if ($first) {       $allowedGroups = "".trim($groupEntry).""; } needs to become: if ($first) {       $allowedGroups = "".trim($groupEntry).""; $first = false; } That should correct it. -Simon 141.83.61.65 16:21, 3 November 2006 (UTC)

Thanks, bug was fixed in version 0.6

magicmonty 17:59, 30 November 2006 (UTC)

Bug with caching and anonymous users is fixed
Hi there, in version 0.6 the bug is fixed. Anonymous users can't access protected pages anymore.

magicmonty 17:57, 30 November 2006 (UTC)

All users
Is there any way to add a catch-all "usergroup" for all users? I would like to set up some pages as read-only for any user, including anonymous, but only allow edit to certain groups. Something like: IT-Support,,*(ro)

This would be great. I'm looking for this functionality as well--Froalskiner 16:33, 23 August 2007 (UTC)

Great extension. Thanks for the nice work. Rigel1 05:26, 3 February 2007 (UTC)

Problem in 1.9
The message is appearing as a hash (eg: �UNIQ26af382d19dd73c6-accesscontrol-00000001-QINU) instead of the restriction notication.

The message is being prepared in the parser, but gets bashed going into output.

Ebowen 18:54, 13 February 2007 (UTC)

Great extension especially for an company intranet but I am getting the same problem under version 1.93. Any fix known?

--Andreas24 14:28, 2 April 2007 (UTC)
 * See this page for solution. Kirill

Same pb under linux AS4 and MW 1.9.3 --Ouaibsky 10:58, 12 April 2007 (UTC)

-- I had the same problem (Wiki-Version 1.10.1 / GBAC1.7) and i solved it by editing the accesscontrol.php in the function displayGroups: there was two times made use of the function $wgOut->parse(...); - change this to $wgOut->addWikiText(...); Attention: this just helps to get the restriction notification again but still adds this ugly UNIQ-line... raZe

MediaWiki-1.6.9: PHP4 does not support passing default function values by reference
I'm using version 0.7 of this extension.

(PHP4) Parse error: parse error, unexpected '=', expecting ')' in /.../wiki/extensions/accesscontrol.php on line 115

Which relates to the following function prototype: function makeGroupTitle($groupEntry, &$readOnly = false)

Delving into the usage of makeGroupTitle, the easiest solution appears to be to take out the default value = false and make sure that all $readOnly parameters passed by reference are properly initialised before calling makeGroupTitle.

Problems adding new internal groups
Xushi: - 12, June, 2007 - 1620 +0300 I noticed the documentation tells the user he has a choice of using the internal groups in MW. But it does not mention how to add extra groups there.

I tried adding with the following,

$wgGroupPermissions['Developers'];

But that didn't show any groups. The only way to show the group is by using the correct syntax,

$wgGroupPermissions['Developers']['read'] = true;

But i don't know how dangerous that is, or if it will override anything.

Problems with
I have installed the access control step by step, and the wiki works fine. However, when adding " testgroup " and then when I save, the page is displayed as "testgroup ". So it does not work. Does this mean it is not reading the accesscontrol.php files? Any help would be appreciated. Marco Pretorius
 * It's a bug which is quite easy to fix:

line 478 of accesscontrol.php should be: $allowedGroups = str_replace("(ro)","",substr($content, $start, $end-$start )); and line 520 of accesscontrol.php should be: $allowedGroups = substr($content, $start, $end-$start );
 * As I'm still extending this extension, I'll supply an enhanced version later. --Jamasi 15:37, 16 June 2007 (UTC)

Thank you Jamasi, I however still have the same problem. Maybe your enhanced version will help.
 * Be sure to check, if the extension did register itself correctly with the parser by taking a look at Special:Version. Additionally you can enable debugging in the extension config and track its workflow. --Jamasi 21:43, 18 June 2007 (UTC)

OK, I figured out the problem. Thanx, Jamasi, it is now registered with the parser and I turned the debuggin on too. I am integrating with AD, so our usernames are case sensitive. What I did was, to take out the "strtolower" parts in accesscontrol.php (line 224 and 280). The access works perfectly now. Just one problem left, when viewing the page it still shows "testgroup ".

I am using the FCKeditor extension. Is this perhaps a bug in that extension, that causes the page to display "testgroup " ? Marco Pretorius


 * the problem you have is that the editor doesn't write but  had the same problem. and you will have that with every extension using such . --Jperl 16:27, 5 August 2007 (UTC)

Call to undefined method Article::getPreloadedText
Hey

I'd like to use your extension, but I always get: Fatal error: Call to undefined method Article::getPreloadedText in \wiki\extensions\AccessControl\accesscontrol.php on line 205 if I put the tags into an article.

(in deutsch: ich krieg immer die sh*** fehlermeldung, der findet nen text net kann des sein??)

Can you help me please.. I have to use this extension ..


 * Had the same issue - are you using mediawiki 1.10.x? If so, set $wgWikiVersion in accesscontrolSettings.php to "1.9" instead of "1.10". (Looks like there is a version comparison between the version number and 1.7 which does not work correctly when the version number goes past 1.9. - line 188 of accesscontrol.php)


 * Bonny 16:43, 28 August 2007 (UTC)

Internal server error in MediaWiki 1.11.0
See http://lists.wikimedia.org/pipermail/mediawiki-l/2007-September/023348.html,

diff accesscontrol.php accesscontrol.php.old 100d99 <              return true; 476d474 <              return true; 551d548 <              return true;