Extension talk:AccessControl/Archive 1

Download

Can You make .tgz version? Not everyone can use git. -- ZoTyA 18:51, 20 August 2008 (UTC)

I second that! This extension looks very useful but I don't quite know how to download it! -- Manu3d 01:28, 23 August 2008 (UTC)

i'll put up a tgz-version once I'll be an autoconfirmed user ... but I doubt this will be useful, see below. -- Thoralf 14:55, 27 August 2008 (UTC)

http://support.dce.felk.cvut.cz/accesscontrol-1.0.tar.gz Want 20:57, 30 August 2008 (UTC)

error: cannot redeclare wfaccesscontrolextension()

just wanted to give this extension a go with mediawiki 1.13 and got this error message in the apache log:

[Wed Aug 27 16:07:05 2008] [error] [client 172.16.5.215] PHP Fatal error:  Cannot redeclare wfaccesscontrolextension() (previously declared in /srv/www/htdocs/mediawiki/extensions/AccessControl.php:59) in /srv/www/htdocs/mediawiki/extensions/AccessControl.php on line 66, referer: http://xxx/wiki/Main_Page

commenting out the require_once...-statement and leaving only the include... line does seem to work, though.

I use extension on mediawiki 1.13, but in my log this is not any error. Want 21:11, 30 August 2008 (UTC)

Line with require_once (number line is 64) is necessery only for loading messages from localization file AccessControl.i18n.php, it doesn't have any influence to functionality of extension. What configuration have you got? The problem could be over there. Want 19:31, 31 August 2008 (UTC)

Isayel 16:34, 16 September 2008 (UTC) confirmed

• Installation
• Step 1:
  • add the following lines to the bottom of your LocalSettings.php:

require_once("extensions/AccessControl.php");
include("extensions/AccessControl.php");

NB: in mediawiki 1.12.0 add ONE of the lines to the bottom of your LocalSettings.php (ok with "require_once" OR "include")

WikiBrik 11:15, 26 November 2008 (CST) noted

• For MediaWiki 1.13.2 the include is redundant and produces PHP fatal error. Installation instructions should be revised...

Error

Hi, when I add your extension I get some "Headers already sent" errors on my wiki:

$wgAccessControlDisableMessages = false; // if false, show a Line on Top of each secured Page, which says, which Groups are allowed to see this page. $wgUseMediaWikiGroups = false; // use the groups from MediaWiki instead of own Usergroup pages $wgAdminCanReadAll = true; // sysop users can read all restricted pages $wgAccessControlDisableMessages = false; // if false, show a Line on Top of each secured Page, which says, which Groups are allowed to see this page. $wgUseMediaWikiGroups = false; // use the groups from MediaWiki instead of own Usergroup pages $wgAdminCanReadAll = true; // sysop users can read all restricted pages 
Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\htdocs\MinjusWiki\LocalSettings.php:1) in C:\xampp\htdocs\MinjusWiki\includes\WebResponse.php on line 10

Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\htdocs\MinjusWiki\LocalSettings.php:1) in C:\xampp\htdocs\MinjusWiki\includes\WebResponse.php on line 10

I'm shure I installed the stuff properly (Mediawiki 1.13.2). --JimHawk 10:25, 17 November 2008 (UTC)

Security Concerns?

Can anyone comment on the security risks associated with this extension? The warning at the top of the page is rather dire, and my clients have asked for this functionality, but I am hesitant to do so until I understand the nature of the risk. Is it simply that access controls can not be "guaranteed" to work, so don't stake your career on "private" articles not being seen by all users? Or can someone gain shell on my mother's toaster, hax0r *pedia and impregnate my goldfish? Seriously though, what are the risks?

Thanks!
Thomsonj 22:57, 11 December 2008 (UTC)

The security risk connected with this extension is following:

• is it possible or is it not possible to break into the shell? - the mediawiki is responsible for it, this extension doesn't have any influence to it. From this point of view the extension is secure.
• In the today appearence the extension could be get round through redirection. If anybody makes a page with redirection to the secured private article, at that time it can be entered by anybody, no matter how the configuration of the rights is put on! That's why this extension is good to make together with others extensions. This is the most serious fault that I would like in the future to get rid of.

NOTICE - Security bug with accessibility on protected page over #REDIRECT was fixed in AccessControl extension v. 1.1

Want 16:41, 23 July 2009 (UTC)

• Also, it's necessary to secure not only the articles but also the lists (so as nobody unauthorized could fill in himself)

Want 16:01, 24 December 2008 (UTC)

Bug when using API

I try to write a bot that works on our local wiki.

But accessing a page via the API generates an error:

Fatal error: Call to a member function getText() on a non-object in /srv/www/vhosts/wiki.pi-consult.de/extensions/AccessControl.php on line 390 

The URL is http://<mywikibase>/api.php?action=query&prop=revisions&titles=BrandMaker&rvprop=content|comment|user&rvdir=older&rvlimit=1&format=xml

Does anybody have a fix for that? --Fez 22:49, 23 January 2009 (UTC)

Need help in MediaWiki 1.14.0

Does this work under MediaWiki version 1.14.0? I can't get it to work. Here's what I did:

• I added the following to the end of the LocalSettings.php file:

$wgExtraNamespaces[100] = "Access";
require_once("extensions/AccessControl.php");

• Created a user account with name "Test"
• Created a page "..mediawiki/index.php/Access:Group", edited the page with the following:

*Test6

• Created a page edited with the following:

Page is being viewed!
<accesscontrol>Access:Group</accesscontrol>

The problem is that any user can view this page, although the text "This page is protected!" appears. Oddly, if I write:

<accesscontrol>Administrators,Access:Group</accesscontrol>

The administrator can view the page, but the user "Test" can't, and goes to a "Wiki:No Access" page.

Any help is much appreciated! Thanks.

• • I'm having the same exact problem. I don't think the thing works in 1.14.

• • Same problem here on 1.14.0. Anyone knows a fix for it? -- Eitch

By my mind is problem in extra namespace "Access" set. Mediawiki filtered page name before tag control in content page. Want 14:13, 16 July 2009 (UTC)

• • I'm using MediaWiki 1.12.0 but I have the same problem. I see the message "This page is protected!" but nothing actually happens in terms of restricting access.

• espacialy when i type: <accesscontrol></accesscontrol>, everyone can read without restriction. <accesscontrol>Administrator, Wayne:Test</accesscontrol> without any content in Wayne:Test, only sysop can read pages. Seems like one more as Administrator or the comma has to be declared. Little bug?! thx alex ADD: Just tested: <accesscontrol></accesscontrol> with comma; <accesscontrol>,</accesscontrol> restrict access. not else. 3h research......

Cannot use MediaWiki::API when Access Control is installed

I'm playing with this extension and it's working well but I can no longer access my site using the Perl module MediaWiki::API when the extension is installed. Perl module uses the MediaWiki API (api.php) to access the Wiki. Have you run across this issue yourself? I should add that simply adding the line "require_once('extensions/AccessControl.php')" to LocalSettings prevents the module or script from accessing the Wiki, I haven't even created groups or access control lists yet. Thanks again.

Cannot use Access Control in a template call

This extension works well for me when I use strings like this in a plain page:

<accesscontrol>Access:Group1</accesscontrol>

However, if I try to call a template from a page, like:

<accesscontrol>Access:{{{groupname}}}</accesscontrol>

it does not work. Your thoughts on this? Thanks again.

Extension do parse accesscontrol tag content. Template is not variable. Want

MediaWiki 1.15.1 Extension AccessControl DOES NOT WORK

We have done every step as desribed in this article HAve created custom namespace PC created page PC:Team included there a *User protected page with <accesscontrol>Administrators, PC:Team</accesscontrol>

And what we see? - User doesnt have access to protected page AT ALL!!!!!!!!

• I'm having the same problem. Doesn't work with MediaWiki 1.15.1

• Have new installed 1.15.1 Wiki, but protection does now work. Protected pages are free available.

• • you bungled the acesscontrol tag, you need to commas after Administrators and not one. Now, you need to comment out include clauses for accesscontrol extension in your LocalSettings.php file and edit the page and fix your accesscontrol tag. Enable accesscontrol extension by removing the comment.

I use Mediawiki version 1.15.0, and no problem. I see problem in fact, that PC have not be really custom namespace, but only "pseudonamespace". Link on problematic page maybe indicated more. Want

Help with MediaWiki 1.15.0

• Well, I use MediaWiki Version 1.15.0, and have the same problems that protection doesn't work heres my Namespace Declaration:

$wgExtraNamespaces[100] = "UserProtect"; also there exists a Site UserProtect:ES with the User Dummy with * in front of it's name and in the Site I want to protect is <accesscontrol>UserProtect:ES</accesscontrol> and I always get the message "This is protected page!" but protection doesn't work, what am I doing wrong? Greets Patrick

Seems to work for me, BUT major looping error messages on every page

Notice: Use of undefined constant next - assumed 'next' in extensions/accesscontrol-1.1/AccessControl.php on line 342

Notice: Uninitialized string offset: 0 in extensions/accesscontrol-1.1/AccessControl.php on line 338

This error only started happening after I created some non-protected redirects in a custom namespace. That is neither the redirect pages or the new pages were protected by AccessControl, but I got this error message for the first time when I visited one of the redirect pages, and the message does not go away. --41.223.4.34 09:35, 9 October 2009 (UTC)

I am having almost the same issue, when trying to upload a file to the wiki, I get the following errors in the php log and then a white screen of death

PHP Notice:  Use of undefined constant next - assumed 'next' in /var/www/html/source/wiki/extensions/accesscontrol-1.1/AccessControl.php on line 342
PHP Notice:  Undefined variable: allow in /var/www/html/source/wiki/extensions/accesscontrol-1.1/AccessControl.php on line 193

latest accesscontrol and wiki 1.15.1

I have excactly the same problem. I switched off PHP notices in php.ini (error_reporting(E_ALL ^ E_NOTICE);), so at least it doesn't generate 6 GB error log files anymore. Cheers, --Till Kraemer 18:14, 16 July 2010 (UTC)

Patches for AccessControl 1.1 in MediaWiki 1.15

I had a number of problems getting the extension to work. I patched the php in three locations and I feel it now works as documented:

• can actually read group list from a namespaced page
• correctly enable/disable edit tab
• support both combinations of "edit" & "read" from page and group list.

My question now is: where should I send my patches? I couldn't find an email address of the author. -- Stephan

My actual mail address is kapica@fel.cvut.cz Want 20:07, 8 February 2010 (UTC)

• Can you make them available somewhere? I am using mediawiki 1.15.1 and have problems as reported from users above! Thanks. -- Papadakos Panagiotis
  • Probably one of them is to change

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

to:

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

• I have some of the problems too! What changes do you make???

Can you post your patch code here? I'm having the same problems. Thanks + cheers, --Till Kraemer 10:16, 21 June 2010 (UTC)

---

I uploaded my changes here. Here's a brief description of the changes:

• accessControl($groups): align with documentation:
  • support reading when page grants (ro) rights to a group
• controlEditAccess(&$editpage): bugfix:
  • do extract groups before processing.
• getUsersFromPages($skupina): align with documentation:
  • do interpret namespace prefix rather than using fixed namespace 0.

HTH.

@kapica: this is a cleaned-up version of the patch I emailed you. -- Stephan 22:01, 4 July 2010 (UTC)

Awesome! Everything works fine now. Thank you so much for uploading it! Cheers, --Till Kraemer 23:08, 14 July 2010 (UTC)

Disabling redirect on Search Pages including protected pages

in includes/specials/specialsearch.php find "goResult(" and replace by "showResult(" will avoid to be redirected automatically to your NO_ACCESS page when a restricted page you don't have access is included in results.

I tried the above code, but it leads to a page not found error. Looking at the code it appears that it should be "showResults(" not "showResult(". However that just leads to a redirect as before.

Seems this is not solved yet... Has anybody found a solution/workaround yet? --217.91.154.83 15:14, 31 January 2011 (UTC)

Yes, see here for a work around

Using mediawiki User Groups

While using this extension i noticed that mediawiki user groups were not called in the correct form. So if you want to give access to users in Administrators and Bureaucrats you have to put the following code on the page: <accesscontrol>sysop, bureaucrat (ro)</accesscontrol> and not as was stated on the extension pages, i.e. <accesscontrol>Administrators, ...</accesscontrol>, cheers, Carlos Sá

1.2 reports as 1.1 on Special:Version page

The 1.2 tarball still has 1.1 set, so that is what appears on the Special:Version page

$ extensions/accesscontrol-1.2$ grep 1.2 *
changelog.txt:version 1.2

$ extensions/accesscontrol-1.2$ grep 1.1 *
AccessControl.php:	'version'		=> '1.1',
changelog.txt:version 1.1
changelog.txt:*Fixes for hook errors in MediaWiki 1.11.0 included

Why don't it show the link to the group which can access the pages?

In the Base Group Access Control extension, <accesscontrol>xxx</accesscontrol> will display the link to xxx, but this version has no this cool function. How can I have it again?

Put in to template can't work

I put "<accesscontrol>My:Group</accesscontrol>" in to a template which plays the role of submenu of a series pages to control the access permission. But it don't work. It should be, shouldn't it?

Error on version 1.16.0

Internal error Detected bug in an extension! Hook hookUserCan failed to return a value; should return true to continue hook processing or false to abort. Backtrace:

1. 0 /home/web/mediawiki/golden-v116-svn/phase3/includes/Title.php(1551): wfRunHooks('userCan', Array)
2. 1 /home/web/mediawiki/golden-v116-svn/phase3/includes/Wiki.php(158): Title->userCanRead()
3. 2 /home/web/mediawiki/golden-v116-svn/phase3/includes/Wiki.php(59): MediaWiki->preliminaryChecks(Object(Title), Object(OutputPage), Object(WebRequest))
4. 3 /home/web/mediawiki/golden-v116-svn/phase3/index.php(117): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
5. 4 {main}

Error on version 1.16.2

Detected bug in an extension! Hook controlEditAccess failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:

#0 /srv/www/Wiki_1.16/includes/EditPage.php(288): wfRunHooks('AlternateEdit', Array)
#1 /srv/www/Wiki_1.16/includes/EditPage.php(271): EditPage->edit()
#2 /srv/www/Wiki_1.16/includes/Wiki.php(553): EditPage->submit()
#3 /srv/www/Wiki_1.16/includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
#4 /srv/www/Wiki_1.16/index.php(117): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
#5 {main}

After installing the extension on version 1.16.2 the above error appears when trying to edit a page. Can somebody help? --WikipediaMaster 12:09, 11 May 2011 (UTC)

Here is the solution: replace all "&$" with "$" in accesscontrol.php file

Here is a complete solution (diff to AccessControl.php)

 diff --git a/AccessControl.php b/AccessControl.php
 index 2fae8e9..d229393 100644
 --- a/AccessControl.php
 +++ b/AccessControl.php
 @@ -372,13 +372,11 @@ function extractGroupsFromContent($content) {
  	return $groupsString;
  }
  
 -function controlEditAccess(&$editpage) {
 +function controlEditAccess($editpage) {
  	/* Hook function for the edit action; */
  	global $wgAllowUserList, $wgUser;
  
 -	$title = $editpage->mTitle;
 -	$editPage = new Article( $title, 0 );
 -	$content = $editPage->getContent();
 +	$content = $editpage->getContent();
  	$groups = makeGroupArray(extractGroupsFromContent($content));
  	$allowedGroups = accessControl($groups);
  
 --

How to make it compatible with 1.17

• apply patch from Stephan here
• comment out Line 60 "$wgParser->disableCache();", and put "$wgEnableParserCache = false;" and "$wgCachePages = false;" into LocalSettings.php instead
• replace all "&$" with "$" in accesscontrol.php file as mentioned above

Compatibility with 1.18 and 1.19 trunk

Will this extension be updated for current mediawiki versions? The patch mentioned above for 1.17 seems to apply to Accesscontrol 1.1, the current version is 1.2. Yet we are unable to get the extension to function in either 1.17, 1.18, or 1.19 trunk. It would be wonderful if a real update could be published! This extension is much needed, thanks for developing it! G.Hagedorn 21:02, 26 September 2011 (UTC)

I would like to help you, but I can't do currently testing on actual version MediaWiki. We plan to upgrade on next month (October 2011), and it will be occassion to apply patch. Want 08:38, 27 September 2011 (UTC)

I do actualization extension based on patch from Stephan Herrmann and Gabor Simon in git repository, but I don't any test changes in our wiki for now! Want 06:55, 21 October 2011 (UTC)

I have good news for you! Today I finished a new version extension AccessControl - 2.0. I want tommorow clean up code. As next step have be save tarball with code on our server. This version is compatibility with MediaWiki >= 1.18 This code used another method of access control, but configs and tags same. Want (talk) 23:33, 13 March 2012 (UTC)

Was trouble with MW1.19-b2 and AccessControl2.0 - There was PHP Warnings: AccessControl.i18n.php failed to open stream: no such file or directory in includes/LocalCache.php Fixed with adding line "require_once("extensions/Accesscontrol/AccessControl.i18n.php");" to the end of LocalSettings.php

Let others pages of the wiki readable and editable by no logged or annonymous user

I installed the AccessControl 1.2 extension, but as expected, others pages of the wiki without the accesscontrol element aren't editable by annonymous user.

How can I do to let its editable by everyone ? Thx --Vincedujag 17:10, 28 October 2011 (UTC)

Errors on WM 1.18

• Fatal error: Call to a member function setCacheTime() on a non-object in /var/www/includes/parser/Parser.php on line 4956

Caused by AccessControl.php line 60: $wgParser->disableCache( );

• Fatal error: Call to a member function addMessagesByLang() on a non-object in /var/www/extensions/accesscontrol-1.2/AccessControl.php on line 64

Caused by AccessControl.php line 64: $wgMessageCache->addMessagesByLang($messages); (wgMessageCache is deprecated in 1.18).

I also experiencing those problems. Is there any solution or temporary hack to bypass them? Thanks. 200.175.235.5 18:46, 23 January 2012 (UTC)

Error if group list is in a namespace (1.18.1)

Hi: I detected an error to retrieve user from a list in a page of other namespace distinct principal. In the line 125 of the current version, the extension retrieve the page from namespace 0 ($gt = $Title->makeTitle( 0, $skupina );), where the first argument is the namespace, but I've created a group list page in namespace 500, so the list is invalid and the extension doesn't work. I replaced the line with another method from Title.php (newFromText) $gt = $Title->newFromText( $skupina ); and it's works. This function is independent of namespace or similar. Is recommended replace this code? Superzerocool (talk) 18:13, 10 April 2012 (UTC)

Paul Wieland says: I patched my own private version to solve this problem. Here is the patched version.

Wildcard

Is there anyway to replicate Extension:Group_Based_Access_Control/AllUsers-0-8Mod , to allow wildcard reads , There seems to be some sort an attempt at doing this in version 2.1 but I cant be bothered reading all the code to work it out why it isn't working.. —The preceding unsigned comment was added by VeNoMouSNZ (talk • contribs) 00:30, 14 May 2012‎

I do not understand of your request. Using wildcards in this expansion is not desirable. AccessControl allows work ordinary users with the non-public data in the wiki. Delegation access rights based on use of wildcards is a potential security problem, if the wiki has no restriction for creating new accounts. Want (talk) 07:15, 14 May 2012 (UTC)

Searchtrouble on MW 1.19.0

Hi, i use 1.19.0 an AccessControl 2.0 and i have a problem with search. Search with * result in "wiki/index.php?search=oracle*&go=Seite&title=Spezial%3ASuche" and e browser-error "connection broken". Have you a idea? (Sorry for my broken English :-)) --Speedy McCat. Keiner ist unnütz, er kann immer noch als schlechtes Beispiel dienen. (talk) 13:41, 18 May 2012 (UTC)

This is problem only for unauthorized user, isn't it? Fulltext search is only for authorized user. Is it because otherwise fulltext would constitute way to get to protected information, which is undesirable. -- Want (talk) 14:54, 18 May 2012 (UTC)

Hi, thanks for the speedy answer. I a admin and the result is the same when i search without "*". The userrights is the same as 1.16.0
When AccessControl disabled, the search is OK. --Speedy McCat. Keiner ist unnütz, er kann immer noch als schlechtes Beispiel dienen. (talk) 18:17, 18 May 2012 (UTC)

The "connection broken"-error coming from never-ending loop from function "fromTemplates", // vložena šablona $rights = allRightTags( getTemplatePage( $templatename ) );. When i disable this section (alone ELSE), it works.

Search-trouble: I have more tested, when i search a item and the item is to a protected title, the search has broken off and the "access denied"-title is displayed. Could you please help me? --Speedy McCat. Keiner ist unnütz, er kann immer noch als schlechtes Beispiel dienen. (talk) 16:53, 21 June 2012 (UTC)

I am sorry, but this is not priority for me. Next four weeks I will in wilderness - out off from network - and I do a important things now. Want (talk) 17:25, 21 June 2012 (UTC)

In addition - I think that this can not be do it in extension, but in the core Mediawiki, because it is point, where must be do it a except for access a authorized users. Want (talk) 17:31, 21 June 2012 (UTC)

Click here for a solution for this problem.

I tried it with 1.20.2, and had the problem when a page I was searching for contained text being searched, putting it in the list of search results, which provoked an error because the "hookUserCan" function in AccessControl.php didn't return a value. To try to fix this, I modified line 341 ("return doRedirect( 'accesscontrol-info-anonymous' );" to "return false;". This forces the search results to return just the title of the page, and then gets a permission error if an unauthorized user tries to open it. This is not a perfect fix, but it is sufficient for my purposes. --Ejcaputo (talk) 10:45, 2 January 2013 (UTC)

I made some modifications to the AccessControl.php program, and now it appears to work ok with MediaWiki user groups. A remaining problem is that the TITLES of protected pages show in the search results. This is fixable in the main MediaWiki source code (SpecialSearch.php, around line 562), but according to comments in that code, it would screw up the paging.

Here is my git directory, which can be unzipped to $IP/extensions/AccessControl:

https://ejc.s3.amazonaws.com/AccessControlGit.zip

Note that this has only been tested (briefly) with MediaWiki 1.20.2. I'm hoping that the author of the extension will review what I did and fix whatever problems remain.

--Ejcaputo (talk) 17:25, 3 January 2013 (UTC)

Support of Mediwiki Groups

Why mediawiki groups is not supported? It introduces additional burder of keeping separate namespaces with groups in case of using LDAP authentication with groups. Is there any chance to bring support back?

Earlier versions worked with these groups, but in the new revision it complicate code. Maybe in time.. But is not problem integrate code of another programmer. Source repository is a official git the Mediawiki. Want (talk) 17:40, 21 June 2012 (UTC)

Click here for a solution for this problem. --Ejcaputo (talk) 17:29, 3 January 2013 (UTC)

Search Problems

Hello,

I've got a problem with the search - function on my mediawiki. Since I have installed the extension "AccessControl", the search doesn't find the right results anymore. I created a couple of test pages, some of them with an accesscontrol - tag and some others without this tag. If I search for content that is in a few articles, I only get the message "MY:No Access ... There is currently no text in this page." Without this extension, I get a list with the results that I expected.

I hope someone can help me.

Notes section added. See here for solution regarding search.

Installation / usage problems MW 1.17

Hi, first of all: thanks for this extension! Looks promising. But I'm having problems with the installation / rights management, hope someone can help. Using MW 1.17 (that's where the problem might have started). 1st try: Downloaded v1.3 manually (AccessControl.php only), but the require_once command made the Wiki shut down completely. 2nd try: downloaded the AccessControl with git, got the 2.0 version, which might not be suitable? Anyway, didn't get any errors, so proceeded with that. Created namespaces according to Manual:Using_custom_namespaces, that worked, they are listed in http://installation_path/api.php?action=query&meta=siteinfo&siprop=namespaces. => Installation step 1 completed. Now step 2 causes trouble, and I'm not sure if I understand the instructions. Say my namespace's ID is 500, name is Foo, with constants defined by "define("NS_FOO", 500);". Then I created a new page called Foo:Foo (first Foo being the namespace, second Foo being the page name), and listed all user names there, like this: *[[:User:User1]]. At this stage, I was already unsure of what exactly to use where (namespace name, ID or constant, how and where to list the users?). Then, I created a template for page protection with <accesscontrol>sysops,Foo:Foo</accesscontrol> , and used that on all pages I wanted to protect. Created a testuser account with normal user rights (not in any user group) - and can still access all "protected" pages with that testuser account. Can anyone help? Much appreciated, thanks! --Justanotherday (talk) 13:37, 17 July 2012 (UTC)

Usernames

Note this extension does NOT support usernames with a full stop in them (.)

Canonical Git repo?

Thanks for working on this! I saw this changeset - does that mean that the Gerrit repository is now the canonical Git repo? Thanks. Sharihareswara (WMF) (talk) 03:44, 3 November 2012 (UTC)

Error on MW version 1.20.4 with AC 2.1

Original exception: exception 'MWException' with message 'Detected bug in an extension! Hook hookUserCan failed to return a value; should return true to continue hook processing or false to abort.' in /var/www/virtual/xxx/html/includes/Hooks.php:245

I've tried some of the suggestions for code changes related to MW 1.16. Didn't help. Any suggestions? Thanks Kaboomki (talk)

---

Update:

I fixed this error by adding "return false;" after ALL LINES that say

doRedirect( 'accesscontrol-info-anonymous' );

Cheers, Marc