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

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)

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:

$wgExtraNamespaces[100] = "Access"; require_once("extensions/AccessControl.php");
 * I added the following to the end of the LocalSettings.php file:

*Test6 Page is being viewed! Access:Group
 * Created a user account with name "Test"
 * Created a page "..mediawiki/index.php/Access:Group", edited the page with the following:
 * Created a page edited with the following:

The problem is that any user can view this page, although the text "This page is protected!" appears. Oddly, if I write: Administrators,Access:Group 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:  , everyone can read without restriction.  Administrator, Wayne:Test  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:    with comma; ,  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:

Access:Group1

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

Access:

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 Administrators, PC:Team

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
$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 UserProtect:ES and I always get the message "This is protected page!" but protection doesn't work, what am I doing wrong? Greets Patrick
 * Well, I use MediaWiki Version 1.15.0, and have the same problems that protection doesn't work heres my Namespace Declaration:

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

function doControlUserAccess( $input, $argv, &$parser ) to: function doControlUserAccess( $input, $argv, $parser )
 * 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
 * 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: HTH.
 * 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.

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