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)

Problem with MediaWiki 1.16.2 + PHP 5.3.5

You need to replace every occurrence of &$ with $ in extensions/accesscontrol.php in order to avoid errors when trying to edit pages with accesscontrols. I'm not really sure, if this action may alter the behaviour of the code, since I do not have the necessary PHP-knowledge. Perhaps someone who's PHP-fluent can have a look, please?

--Katwol 11:08, 7 February 2011 (UTC)

Problem with PHP 5.3 (solved)

Update + Solution:

Changing the following line in accesscontrol.php from:

function doControlUserAccess( $input, $argv, &$parser )

to:

function doControlUserAccess( $input, $argv, $parser )

seems to solve the problem and lets the extension work as wanted! :-)

--Katwol 11:07, 24 August 2009 (UTC)

Worked fine for me. Thank You. Is it a typing error by the original editor? --Roemer2201 19:48, 24 May 2010 (UTC)

Update: I cannot see the access-information on any pages anymore, and the access-control only works partly, as users can see any page, whether they are supposed to or not, but the editing-access-control seems to work...

--Katwol 06:55, 19 August 2009 (UTC)

After upgrading to Xampp 1.7.2 I get the following error whenever I call-up a wiki-page with the <accesscontrol>-tag at the top.

Warning: Parameter 3 to doControlUserAccess() expected to be a reference, value given in /opt/lampp/htdocs/_fhbwiki/includes/parser/Parser.php on line 3243

Does anybody has an idea what to do about that? Thanks!

Everything works ok with:
MediaWiki 1.14.0
PHP 5.2.9 (apache2handler)
MySQL 5.1.33

But the error occurs with:
MediaWiki 1.15.1
PHP 5.3.0 (apache2handler)
MySQL 5.1.37

--Katwol 10:15, 18 August 2009 (UTC)

The first solution did not help, but I changed the line from:

function controlEditAccess(&$editpage)

to

function controlEditAccess($editpage)

I'm running:
MediaWiki 1.18.1
PHP 5.3.6-13ubuntu3.6 (apache2handler)
MySQL 5.5.20

Roemer2201 (talk) 12:17, 20 March 2012 (UTC)

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

• Multiple <accesscontrol>-tags : Also, I noticed that it is not possible to have more than one set of <accesscontrol>-tags on any single page. This would be helpful to use in templates/categories...
• Use of template placeholders ( {{{1}}} ) 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..

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)

• Enable <readonly> access for another groups, example:

<accesscontrol>IT-Department,Management</accesscontrol>
<readonly>Sales,,Purchasing</readonly>

• 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.

• Disable the edit button if the user is not allowed to edit the page.

• Fix the error where anon users can't read pages marked anon(ro).

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 <accesscontrol>-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:

<accesscontrol>IT-Support,,*(ro)</accesscontrol>

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?

I got the "*(ro)" working. Add the following else if to the extension: if(in_array($groupTitle, $wgUsermGroups)) { debugme("controlMediaWikiUserAccess_5: user in group '".$groupTitle."', so access is granted"); if ($showGroupText) { return( displayGroups($groupsToDisplay) ); } else { return true; } } else if ($groupTitle == '*') { debugme("controlMediaWikiUserAccess_4: user in group '".$groupTitle."', so access is granted"); if ($showGroupText) { return( displayGroups($groupsToDisplay) ); } else { return true; }

}

hi! i'm interest with "*(ro). can i know where should i add the code above? is it inside AccessControl.php? i got work with this "all(ro)" in another machine before, but when i do in another machine, "all(ro)" can't use anymore. any idea?

I modified version 0.8 to enable the use of "*" for all users no matter what group access method you use. Extension:Group_Based_Access_Control/AllUsers-0-8Mod TazzyTazzy 19:30, 13 January 2010 (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 <accesscontrol>

I have installed the access control step by step, and the wiki works fine. However, when adding "<accesscontrol>testgroup</accesscontrol>" and then when I save, the page is displayed as "testgroup</accesscontrol>". 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</accesscontrol>".

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

the problem you have is that the editor doesn't write <accesscontrol> but

<accesscontrol>

had the same problem. and you will have that with every extension using such <tags>. --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 mailarchive: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

I'm finding that commenting out the doRedirect() from line 298, or commenting out line 71: "$wgHooks['userCan'][] = 'hookUserCan';" per comments here results in a working search, however any protection seems to be lost (i.e. an unregistered user can get to protected pages. --24.213.146.240 14:42, 10 March 2008 (UTC)

I'm trying that using version 0.8 and mediawiki 1.12, without successful, any idea? --Tuxer 10:13, 29 March 2008 (UTC)

I too would be interested in a work around (to at least not show results for secured pages, just ones that can be accessed), anything that gets search somewhat working, even at the exclusion of pages with accesscontrol tags on them. If anyone can come up with something, it'd be appreciated. --Andrew Hodder 15:06, 3 April 2008 (UTC)

Per the above earlier comment "commenting out line 71: "$wgHooks['userCan'][] = 'hookUserCan';" per comments here results in a working search, however any protection seems to be lost ", I implemented this "fix" and it works for our situation here. The access control is still in place on the pages directly, search also works. The only downside is in the search results you can read a small blurb from the restricted page. Which we can live with here. Though a long term fix to exclude the "blurb" text and simply show the article title in the search results would be highly appreciated. Andrew Hodder 22:29, 7 April 2008 (UTC)

Has anyone been working on this long-term fix as proposed by Hodder? It would be EXTREMELY useful. Soonshort 12:01, 29 July 2008 (UTC)

With a short e-mailed blessing from this extension's author, I just published a drop-in replacement fork/rewrite (Extension:Improved Access Control) that addresses these issues among others. It unfortunately requires a tiny patch, but you may find it useful. Any comments appreciated! JEisen 17:13, 7 November 2008 (UTC)

Case in large wikis

In wikis with a large number of articles, protecting pages is similar to blocking search access as the probabilities of finding protected text go up--62.15.136.254 18:03, 12 February 2008 (UTC)

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.

• FIXED. Apparently changing $wgWikiVersion to 1.8 fixed this problem (I'm running 1.10 and had it set at 1.9 (see the issue with setting it above 1.9)).

Pages with <accesscontrol> return blank

I implemented the extension and added the user group Administrator Usergroup:Administrator

• admin_log_in_id

I then added <accesscontrol>Administrator</accesscontrol> to another user group page Usergroup:Design

• designer_log_in_id1
• designer_log_in_id2

<accesscontrol>Administrator</accesscontrol> 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?

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

user group pages only accessible by sysop

I have loaded and configured the extension, sysop can see and modify anything but usergroup:simple member can search the page, not a problem, but when they click the link they get a 404 error

the debug shows the user is found in one of the usergroup listings but still get the 404 error, does not happen for non restricted pages

access header is <accesscontrol>Administrator,, Simple(ro),, Other(ro)</accesscontrol>

Extension doesn't seem to work on wiki installed not on root folder (MediaWiki 1.11, extension v0.8)

I have MediaWiki 1.11 and the extension v0.8 running, and the extension doesn't seem to work -- the sysop can access all pages, while non-sysop users in various groups cannot access any of the pages that they should be able to. Furthermore, *any* user seems to have access to Usergroup:groupname pages! This appears to be because I don't have the wiki installed off a root folder. E.g. When the top of a restricted page says "This page is only accessible for group CoolUsers !!!", you can click on CoolUsers and you should go to the list of that group of users. However, it wants to go to http://sitename.com/index.php/Usergroup:CoolUsers, I guess because it thinks the wiki is on http://sitename.com. But my wiki is in a subfolder and also seems to use ?title= format rather than just a slash, so the right link should be http://sitaname.com/~username/wikiname/index.php?title=Usergroup:CoolUsers. I can't seem to do this. And, probably for a similar reason access to Usergroup:Coolusers is not restricted to sysops, but is allowed to any user.. Help anyone?

I am having the same problem. If a user has modified their settings to get rid of "ugly URLS", like I did, it appears this extension will not function. Does anyone know where the "?title=" comes from in the code? --Liface 11:32, 7 April 2008 (UTC)

Just an addition: This doesn't actually have to do with the Short URLs, it still doesn't work after I disabled them. --Liface 11:52, 8 April 2008 (UTC)

This problem can be fixed by changing the last command of function parseLink (from accesscontrol.php) to 'return "<a href=\"$wgScript/$linkTitle\" title=\"$linkTitle\">$linkName</a>";' and adding 'global $wgScript;' as the very first line of the function.

I did something similar: I changed the line after the comment "return the html link" to return "<a href=\"/zuvwiki/index.php/$linkTitle\" title=\"$linkTitle\">$linkName</a>";. So this is not the dynamic solution, but how often do you change the directory-name of your wiki? In addition i like to mention, that it startet working after editing a protected page and saving it. Before that it still pointed to the root-Directory. Maybe thats an issue with the caching of mediawiki. Keep that in mind. Roemer2201 07:59, 13 August 2010 (UTC)

Is it working with 1.9.3?

Hi! I tested accesscontrol 0.7. and 0.8 on mediawiki 1.9.3. I understood the manual that 0.7. is working with 1.9.3. and 0.8 not. but I receive always (with both versions) an No_Access page to restricted pages even if Im a user of the allowed group. Only the WikiSysop has access.

Is accesscontrol working with 1.9.3 or do I have to use another mediawiki-version? Thank you for every help!

Kai

0.7 works on 1.9.3. Vic 08:40, 18 January 2008 (UTC)

RESOLVED Careful on MW 1.11.0!!!

I installed this extension and now everthing is broken (I guess so)
First there was just a problem on one article I tried to protect. After restarting Apache I have no access to any Page of my Wiki...
Error Message is: 404 Not Found. My server definitly is alive. I am redirected to my "Kein_Zugriff" Article (as url is No_Access?!?) though I defined the german version! Anyway even this page could not be found! If I type in any page I can remember there is the same issue! Could be a bug?
Maybe a problem on my server?
Just be careful.
If I resolve this problem I'll post it
--84.186.215.218 09:29, 18 January 2008 (UTC)

That was a shock...
I installed another accesscontrol extension previously and there was the problem :)
now everything is fine--84.186.215.218 09:34, 18 January 2008 (UTC)

Feature request: Default values

Is there any way to add default access control values for new pages? Tried forcing the tags into the style, but stops working if I insert a second tag--62.15.136.254 15:21, 7 February 2008 (UTC)

Using LDAP/Group Based Access Control, MW 1.11. Test Page won't let me back in. (FIXED!)

I've used this Extension before (access control) without issue. Installing it on a fresh wiki, which pulls the groups from the LDAP (which I believe is a non-issue in this case, but felt I should mention it).

Settings look fine for our purposes:

       $wgWikiVersion = 1.11;
       $wgUseMediaWikiGroups = true;
       $wgAdminCanReadAll = true; 

I've created a Test_page article and added the accesscontrol "lock" for the sysadmin(ro), as you can see below. Now, not only can my users assigned to the sysadmin group not see the page (redirections to my no_access), but my account which is both sysadmin AND a local SysOp/Bureaucrat can't get to this page either.

It should be noted when I first saved the page out, it displayed the "only viewable by the sysadmin(ro) group!" message just fine. The moment I refreshed however, it locked me out. I also have all of the caching disabled per others comments.

Checking my debug output, I don't see what it's doing wrong. It sees the user's group and the accesscontrol for the page match, yet it denies access:

hookUserCan_1: -- Begin content --
hookUserCan_2: this is a test!

<accesscontrol>sysadmin(ro)</accesscontrol>
hookUserCan_3: -- End content --
hookUserCan_4: accesscontrol tag found
hookUserCan_5: sysadmin</accesscontrol>
controlMediaWikiUserAccess_1: 10.1.3.107
getGroupsToDisplay_1: Extracted Group Title: sysadmin</accesscontrol>
controlMediaWikiUserAccess_3: Group = sysadmin</accesscontrol>
controlMediaWikiUserAccess_6: user access denied
hookUserCan_1: -- Begin content --
hookUserCan_2: Access to this page is denied.
hookUserCan_3: -- End content --

I've tried changing $wgWikiVersion to 1.8 per the above comments on a similar situation (though it makes little difference from my 1.11 setting, per looking at the code, 1.7>= is all that matters). But it doesn't help.

Any ideas?

Andrew Hodder 22:01, 19 February 2008 (UTC)

Well, figured it out. The answer was similar (but not the same) to the solution to "Problems with <accesscontrol>". Thankfully someone else ran across this:

This problem due to function "hookUserCan". You must replace the line:
"$allowedGroups = str_replace("(ro)","",substr($content, $start, $end-strlen($endtag)+1 ));"
by:
"$allowedGroups = str_replace("(ro)","",substr($content, $start, $end-$start ));"

And of course this should affect all MW 1.11.X users, since hook functions are now required to return data.

The moment I made this change, everything started working as it should. The tip-off was what I was seeing the debug log, as you can now see, I'm no longer getting the </accesscontrol> end tag dumped into the variable when it checks for the group access:

hookUserCan_5: sysadmin
controlMediaWikiUserAccess_1: Ahodder
getGroupsToDisplay_1: Extracted Group Title: sysadmin
controlMediaWikiUserAccess_3: Group = sysadmin
controlMediaWikiUserAccess_5: user in group 'sysadmin', so access is granted

Props go out to Mathias for the fix! [1]

I should also note, I changed the version variable back just to ensure that bug (anything greater than 1.9 in the variable) didn't kick in. Though that didn't "fix" anything, just kept me from running into more issues down the road.

$wgWikiVersion = 1.8;

Andrew Hodder 21:25, 3 March 2008 (UTC)

Actually I should note that I forgot to implement that fix earlier on the non-read only section as well (which I never noticed until I tried to edit a protected page when I wasn't logged in as WikiSysOp). So I had to correct this as well:

Changed accesscontrol.php on line 565 from:
$allowedGroups = substr($content, $start, $end-strlen($endtag)+1 ));
to:
$allowedGroups = substr($content, $start, $end-$start);

No known issues aside from the problem with doing searches on protected pages.

Andrew Hodder 18:39, 31 March 2008 (UTC)

Useful patch

I don't know PHP enough. I'd tested it and it is working. But please check it. In my opinion $wgAccessControlNoAccessPage should be transformed via $wgArticlePath, too.

--- accesscontrol.php.old       2008-02-27 09:40:06.133696664 +0100
+++ accesscontrol.php   2008-02-27 09:37:42.760736414 +0100
@@ -385,6 +385,7 @@
        // Parses a Wiki-Link and generates a HTML-Link (this is quite a bad hack)
         function parseLink($link)
        {
+               global $wgArticlePath;
                // Check if Link is marked "Read Only"
                if (strpos( $link, "(ro)"))
                {
@@ -416,8 +417,9 @@
                                 $linkName = $linkTitle;
                 }

-               // return the HTML link
-                return "<a href=\"/index.php/$linkTitle\" title=\"$linkTitle\">$linkName</a>";
+               $url = str_replace( "$1", $linkTitle, $wgArticlePath );
+
+                return "<a href=\"$url\" title=\"$linkTitle\">$linkName</a>";
         }

Transclusion

I found a flaw on this extension. Say page [[ABC]] is restricted. People can just easily create new page and transclude page [[ABC]] to view it ({{:ABC}}). Borgx 00:12, 16 April 2008 (UTC)

Access Control on MW 1.12?

I am using mediawiki 1.12 and have been experiencing the same problem as Johann. The user who should not be able to view the page gets to view it and is redirected to the no_access page only when trying to edit the page. Is there a solution to this problem? Or did I make a mistake in some settings?Thanks --Jamlc 20:44, 18 April 2008 (UTC)

RDO (26.05.2008): I thought i had the same problem.... until i found out that it seemed to be a chachingproblem... by disabling caching ( i used the following line in my LocalSettings.php) all worked properly (including transcluded content!). Unfortunately bey doing this you disable caching at all - keep that in mind!

The codeline: $wgCacheEpoch = date("YmdHis");

accesscontrol on 1.11 no anonymous access

I'm having problems with a system that is redirecting Special:Userlogin to the No_access page, but not all the time. It seems to come and go. I've been completely unable to find out what is causing it. People already logged in are fine, but if a user isn't logged in and try to access the Main page they get the you must login page, when they try to click Special:Userlogin they are redirected to the No_access page, of which they can't view so they are given the you must login page again.

-Bill 8 May 2008

Well it hit again so I decided to try disabling the cache with "$wgCacheEpoch = date("YmdHis");" as noted above. It does seem to have fixed it for now. I guess I'll see if it happens again.

-Bill 11 June 2008

Nope, the above didn't fix it as the problem came back again later.

MW v1.9.3 Not Working

MS1.9.3, PHP 5.2.5, Mysql 5.051a.

After adding the lines to LocalSettings.php, my pages turn blank and won't come up. Any ideas?

Thanks.

What is allowed on a Usergroup: page?

I want to leave a message for future sysops on the page about how it works and how to deal with it. Is anything like this supported? 92.224.225.173 22:25, 8 July 2008 (UTC)

Fork/Rewrite

With permission from the author, I just published a drop-in replacement fork/rewrite (Extension:Improved Access Control) that addresses a few of the issues I've seen on this page and used the security issues with authorization extensions page as a checklist for securing it further. I've been using it on a moderately active site for about 6 weeks very successfully, after a few years of using this extension until the search issues became too problematic. It currently requires a small patch for some functionality, but I'm trying to fix that and you don't need it for most features. (Sorry if this is poor form -- I owe a lot of thanks to Martin for the work he put into this extension and wouldn't be forking it if he didn't tell me he didn't have the time he wanted to put in these features, and I'd be honored if he wanted to fold them back into this version.) JEisen 17:26, 7 November 2008 (UTC)

Users instead of Usergroups?

Is it possible to use access only to a user, not a usergroup? Or must I make a usergroup for each user?

I wish for each user to have some subpages that only they can view on their User: page. 99.120.19.221

Error in code

There appears to be an error in accesscontrol.php at about line 420 if the wiki is not at the root of the fileserver. The existing code reads:

// return the HTML link
return "<a href=\"/index.php/$linkTitle\" title=\"$linkTitle\">$linkName</a>";

I belive it should read:

// return the HTML link
global $wgScriptPath;
return "<a href=\"$wgScriptPath/index.php/$linkTitle\" title=\"$linkTitle\">$linkName</a>";