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

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


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

Bugs (no fixed)
The plugin has typical crappy PHP bug (there's big difference between !== and !=). allRightTags function shall be like this:

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:

The URL is http:// /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)