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)

I would also really appreciate such an option " *(ro) "....is there already something like this??thanks for answer

I'm also looking for this function. I'm running MW 1.11, PHP5 and Extn 0.8. In the AccessContolSettings.php there's $wgAccessControlAnonymousGroupName = "anon"; but when I add that group name into the body of a page as (ro) anonymous users still get the No_Access page displayed. Does anyone know how to make pages read-only for unregistererd users?

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;

ADD 25/09/2007

Yes I have this error with MediaWiki 1.11.0, but I don't know what to do with the code that you gave.

If someone has a more accessible tip, I'll be happy

Thanks, Matt

ADD 25/09/2007

For example 100d99 <              return true; means: add "return true;" at line 100 in accesscontrol.php. In MW version 1.11 every "hook" function must return value.

Patched version: http://www.volny.cz/ook/accesscontrol.zip

Jiri

Redirect Issues
Using MediaWiki 1.11 with "Short_URL"


 * Created User1 and User2
 * Neither are sysops.
 * User1 was given rights to access pages assigned to Usergroup:Groupname

Whenever User1 or User2 attempt to access the actual page /Usergroup:Groupname/, they were getting 404 error.

Specifically, it was taking them to:

http://domain.comno_access/

Patched code accordingly and now User1 and User2 are both sent to /No_Access/ instead:

540       if (!in_array("sysop", $wgUser->mGroups)) 541           {    542            //redirect to the no-access-page if current user isn't a sysop

(-)543           $wgOut->redirect($wgAccessControlNoAccessPage); (+)543           doRedirect;

544   545            return false; 546                        }    547                 }    548         else 549        return true;

However, whenever User2 performs a search looking for "any" terms that is on the protected page, they are still being redirected to

http://domain.comno_access/

Any ideas?

-Marc

Problem with multiple Wikis on same server
Access control does not seem to work correctly on server with multiple wikis (Wiki version 1.10.1 & access control 0.8) I have following wikis:
 * www.domain.fi/wiki1
 * www.domain.fi/wiki2
 * www.domain.fi/wiki3
 * etc

Problem is that when I create access controlled page on wiki2 it somehow points to wiki1 if the user have no access. Also AccessControl message which says for example that This page is accessible for usergroup admin only points to wiki1 (www.domain.fi/wiki1/index.php/Usergroup:Admin)

Ideas?


 * Problem 1 solved, I forgot to put $wgAccessControlNoAccessPage = "/wiki2/index.php/No_Access";
 * problem 2 needs little bit editing to accesscontrol.php

CGI Error with 1.11.0?
It seems to work fine... the tag works, it renders correctly for group users, denies non-group users, etc... EXCEPT when I access a controlled page as a "non-user", it gives me this error:

CGI Error

The specified CGI application misbehaved by not returning a complete set of HTTP headers.

Instead of directing me to the No_Access page. Any ideas?

--216.99.65.63 18:55, 15 October 2007 (UTC)

Search results on protected documents
Using version 0.8 on MediaWiki 1.11.0 I noticed that searching gives some undesireable results.


 * protected pages are not found by page- or full-text search if read permission is not granted (which is good) - instead, I get the "No Access" page.
 * when searching full-text for a word that is present in an unprotected AND a protected document, I also get "No Access" as the resulting page instead of a single hit.

I think it would certainly make more sense to just silently skip all results a searching user is not authorized to see.

However, I've got a hunch that this is probably outside of the scope of this extension but really about how searching is done - or isn't it?

Added later:

This is not entirely true: There are two problems with the code that will lead to this behaviour:


 * function controlUserAccess is doing the redirection before returning the "false" result - so when the wiki checks for access rights, the redirection takes place before the result is passed on to userCan
 * the userCanHook does not pass the result back, as $result is not set to the result of either controlMediaWikiUserAccess(...) or controlUserAccess(...)

A quick hack would be to remove the doRedirect from the controlUserAccess and change userCanHook to set $result to whatever the control...-functions return.

This seems to work but -alas- the user is now served the mediaWiki's default Permission-Error page where it says "The action you have requested is limited to users in one of the groups *, user." - which is nonsense, of course.

But apart from this glitch it's working pretty well :-)

--Ulrich

LDAP extension and Group Based Access Extension - Always Getting No Access Page
Has anyone gotten both of these extensions to work together? I have LDAP working perfectly but this extension doesn't seem to work too well with it.

Whenever I create a page with the accesscontrol tag and the group's inside it - it results in a No Access Page regardless if you're in that group or not. I thought it had to do with the case sensitivity of the AD usernames but even when I took out the 'strtolower' function in accesscontrol.php it still has the same results.

Pages with return blank
I implemented the extension and added the user group Administrator Usergroup:Administrator
 * admin_log_in_id

I then added Administrator to another user group page Usergroup:Design Administrator any attempt to access the page returns a blank page, not even redirected to the no_access page the version page shows that the extension is loaded Extension functions wfAccessControlExtension and when I disable the extension the page loads fine MW version 1.11.0 any ideas?
 * designer_log_in_id1
 * designer_log_in_id2
 * i was able fix this --
 * in the accesscontrolSettings.php where it asks for the version number I had 1.11, the code does not recognize this as a higher version than 1.7 so runs the 1.6 simulated code - code needs to be adjusted to break out the version numbers to allow for 1.11 being greater than 1.7, can be fixed by setting $wgWikiVersion to be a value of between 1.7-1.9, I set this to 1.8 an the code/extension is now functioning