Extension talk:AccessControl

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)

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

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)