Extension:AccessControl/gu

MediaWiki extensions manual

AccessControl Release status: stable
Implementation	User rights , Parser extension , Tag
Description	Allows restricting access to specific pages based on internal groups or group lists from userspace
Author(s)	Aleš Kapica (Wantચર્ચા)
Latest version	6.0 (2023-03-01)
Compatibility policy	Master maintains backward compatibility.
MediaWiki	1.34+
PHP	7.4+
Database changes	No
License	GNU General Public License 2.0 or later
Download	Git [?]: Download Git master browse repository (Phabricator · GitHub) commit history repository contributors (GitHub) code review
Example	Support DCEwiki or Thewoodcraft.org
Parameters $wgAdminCanReadAll $wgAccessToHistory $wgAccessControlRedirect $wgAccessControlMeta $wgAccessControlNamespaces
Tags ‎<accesscontrol> (not need anymore)
Hooks used EditPage::attemptSave ModifyExportQuery ParserBeforeStrip ParserFirstCallInit ShowSearchHit getUserPermissionsErrors
Quarterly downloads	55 (Ranked 84th)
Translate the AccessControl extension if it is available at translatewiki.net
Issues	Open tasks · Report a bug

The AccessControl extension allows restricting access to specific pages based on internal groups or group lists from user space.

MediaWiki in its default state is not designed as a Content Management System (CMS), but when used as a corporate or school intranet it is required to protect sensitive data. AccessControl has been developed for this purpose.

How this extension meets the requirements for site security

Warning:

It is recommended to use the latest stable version of MediaWiki because older versions of MediaWiki can be bypassed by different methods!

Atom/RSS feeds, diff, & revision links : Page content is protected, but when opening a page from history a piece of raw content will appear. If the <accesscontrol> tag was placed at the beginning, a potential attacker may be able to see the names of contributing users!

Listings & search : Unless otherwise noted, if there is any page with protected content in search results, the user is redirected away. Since extension version 2.5, searching may be allowed too. But it should be borne in mind that the displayed search results can compromise sensitive data. Therefore, do not write in your wiki sensitive information, such as passwords, that could be obtained through a fulltext search if searching through the contents of pages protected through an access control is allowed!

Inclusion/transclusion, related rights, & other extensions: Pages containing the <accesscontrol> tag, or including another page protected by the <accesscontrol> tag, are secure. The <accesscontrol> tag is processed in raw wikitext before HTML conversion.

Warning:

When using Extension:DynamicPageList3 , you must know that this extension selects from content pages before the parser analyzes wikitext. Protection of generated pages by an <accesscontrol> tag depends on the tag being included in the content of new page.

Redirects: The problem with redirection was repaired in version 1.1

API & action links: For each anonymous user the action class is automatically set to false, besides the view attribute for unprotected pages. Allowed actions for authorized users depend on the permissions settings of MediaWiki and the username listed in the access list pages use.

Edit Section & watching pages: Options are available only to registered users if they are logged in and are on the security access list.

Files & images

Warning:

The extension AccessControl does not protect files against direct access via URL! If files cannot be publicly available, they must be protected at the server level!

XML export (Special:Export)

Warning: AccessControl version < 2.0, was based on a hook unprotected from MediaWiki's side before exporting pages to raw code. Therefore, if you use AccessControl version < 2.0, you must prohibit the special page to prohibit exporting the pages from MediaWiki.

Author backdoor

Extension AccessControl does not have a backdoor!

Caching

I recommend turning off caching. See the previous paragraphs.

More info about potential problems regarding security is on the page Security issues with authorization extensions .

Features

Since version 2.1 the extension examines the embedded page or template as well.

• Easy to set up and simple to use.
• No patches to MediaWiki core.
• Unlimited groups.
• Dual mode access control:
  • View control.
  • Edit control, including restrictions on manual edit access when using action=edit in the URL.
• User groups may use any namespace.
  • Namespaces with group lists may be protected by another extension.
• MediaWiki sysop group may view and edit the protected pages.
  • Controlled by extension variable $wgAdminCanReadAll
• Access may be granted to multiple groups
• Read-only access may be granted to both groups and individual users.
• Unauthorized users can use the search feature only if is it allowed. See how this extension meets the requirements for site security.

Documentation

Manual (in Czech language for now) here as wiki page, but is prepared for translation. If you want to contribute to creating an English version, you must donate any amount of money to pay for a commercial translator, because the author does not have the time and skills for it. The man page (for now only Czech version) is part of the source code, and can be imported into your private MediaWiki instance if you want.

Installation

Step 1: Local Settings File

• First check that you have set these variables in the LocalSettings.php file. If not, set them:

$wgGroupPermissions['*']['read']            = true;
$wgGroupPermissions['*']['createaccount']   = false;
$wgGroupPermissions['*']['edit']            = false;
$wgGroupPermissions['*']['writeapi']        = false;
$wgGroupPermissions['*']['createpage']      = false;
$wgGroupPermissions['*']['createtalk']      = false;

• Add the following lines to the bottom of your LocalSettings.php:

wfLoadExtension( 'AccessControl' );

Is recommend unavailable the Special pages, which may be used to compromitation the content of your wiki by anonymous bots or users. Read 'README' file, where is example protection code for LocalSettings.php

Warning:

Watch out for the $wgAccessControlRedirect variable! This is only for developers to get a view at the contents of the debug messages, if needed. In production must be value every false.

Step 2: Read manual

Version 6.0 supports the old syntax of this extension. New syntax based on template parameters is very sophisticated. But for base use we can still use AccessList created by the old syntax, and protect pages by element accesscontrol.

Using

The new version has a new access rights setting system, based on template parameterization. If the parser encounters any of the following parameters while processing a template, it will call AccessControl to check if the user has access to the content.

isProtectedBy - સભ્ય સમૂહોની યાદી

readOnlyAllowedGroups - User groups with read-only access

editAllowedGroups - User groups with edit access

readOnlyAllowedUsers - List of users who can only read the content of the site

editAllowedUsers - A list of users with editing rights

Within a single template, all of the above parameters can be used at the same time, so the indentation indicates their hierarchical position in terms of rights. You will learn more in the description of each parameter, where examples will also be given.

editAllowedUsers

Using this parameter turns a regular template into a list of users. Each user whose name is specified in this parameter will have the right to edit the page into which the template with this parameter will be inserted. And also all pages that use it in the isProtectedBy parameter. If more than one user is specified, their usernames are separated by a comma.

Simple example self-protected page (i.e. 'MyPage') where is in code used 'Template:Warning':

{{Warning
|1=This page is protected
|editAllowedUsers=John Doe, Jane Doe
}}

I can be used to protection another page, if the WikiText content use any template with the parameter 'isProtectedBy', where is as value name the self-protected page 'MyPage'. ઉદાહરણ જુઓઃ

…
| isProtectedBy = MyPage
…

It can be (not must!) edited by Page Form.

Remember that MediaWiki uses transclusion. If anybody editor use this page, for tranclusion, may unavailabeled more pages in site! AccessControl is used where the 'edit' action is only allowed for verified users. Extensions ConfirmAccount and ConfirmEdit (CAPTCHA) recommend.

Using of the old syntax

First create User Groups. It may be any page stored in the main namespace, only colon must be after first word in the name. User lists can be a page in the namespace titled "Department" Each username appears as a list item.

* John Doe
* Jane Doe (ro)

User names listed with "(ro)" at the end can only read the protected article, not edit it. For other groups of users, you can create another member list with the name Department in another namespace. Note that the user's name must start with a capital letter!

Example tag code

<accesscontrol>Administrators,IT:Department,Sales(ro)</accesscontrol>

Configuration

• Check the settings in extension.json file.

These can be set in LocalSettings.php:

$wgAdminCanReadAll = true; // Administrators can read all restricted pages

• Depending on localization, your wiki needs pages created to which anonymous or unauthorized users will be redirected. You have to create them in advance because some of them can't access pages from another page.
• The safety of the page is provided by the <accesscontrol> tag. If there isn't a tag or the page is empty, it's freely accessible to logged-in users that can read and edit the page. No user, logged in or anonymous, will have read-only access.
• Members from groups listed in the <accesscontrol> tag can edit the page only if the group title isn't listed with "(ro)" and if they don't have read only access set in the group member list.
• By default the variable $wgAdminCanReadAll is set to true so that members of the sysop group can edit user group pages in any namespace.

Warning:

When set to false, members of the sysop group can't read and edit pages protected with the <accesscontrol> tag, which may lead to big trouble. This can only be remedied on the code level.

Attention

For version < 4.1

MediaWiki versions:

1.29 – 1.36

If for some reason you cannot upgrade your MediaWiki to version 1.39 LTS, you can continue to use version 4.1 of the form-support branch. If you have a problem with the update, because any problem occurred and blocked your actualization, write in the discussion. MediaWiki is very complexity software, and sometime a little bug may be as big problem for admins without the programming experiences.

A new version (4.0) of the extension in the separate branch form-support was developed for using with the Extension:Page Forms – as accesslist you may use any template, but the old syntax of accesslists is supported.

Changes for using with the VisualEditor was implemented too.

You may get code from git:

git clone -b form-support https://gerrit.wikimedia.org/r/p/mediawiki/extensions/AccessControl.git

Warning:

Versions 3.x are obsolete, and an upgrade is recommended, because these versions don't check before saving the code if the template includes itself. MediaWiki allows it, but the result is a looped and inaccessible page. The only solution for this is to disable the AccessControl extension, remove the problematic code from the page, and then reenable.

If your MediaWiki Version (≥ 2.6) isn't recommend for use, because have not support of the maintainer.

MediaWiki versions:

1.21 – 1.28

Version 2.5.1 is strongly recommended to be used.

For version < 2.3

• There was a problem in function fromTemplate() causing AccessControl to ignore tags from included pages or templates. Actualization is recommended!

For version ≥ 2.0

MediaWiki versions:

1.18 – 1.20

Warning:

From version 2.0 the extension does not use wiki user groups (except sysop), only groups created by user access lists!

• Pages can have only one <accesscontrol> element.
• If the user is a member of multiple groups, the group that gives them more access is assumed.
• This extension uses a MediaWiki hook that is called whenever a search result is displayed. This means that a page that has an ACL will trigger an "Access Denied" message for end users who happen to search for text contained in a protected page. A simple solution is to put pages that require AccessControl into another namespace and then disable searching for that namespace. Although this isn't really a bug, it is undesirable behavior. Click here for an example showing a work around.

Warning:

MediaWiki >= 1.21 contains new a framework ContentHandler and extension version 2.1 is unusable. Use AccessControl version 2.2 which is updated for MediaWiki 1.21 and above.

For version ≤ 1.3

MediaWiki version:

≤ 1.17

• Groups from MediaWiki must not be in localized form! sysop cannot be Správce, etc.
• A page may have multiple <accesscontrol> elements, with access accepted from groups in any tag.
• Anonymous users do not have access to pages protected by <accesscontrol> elements.
• If variable $wgAdminCanReadAll is true, sysops always have edit access.

MediaWiki Version Testing

Version 6.0 (based on branch form-support) was actualized and tested on MediaWiki 1.39.2 the current stable release of long-term support (November 2026), and merged into master branch of git repository.

• Version 4.1 from branch form-support of git repository (see link for clone on top of this page) was tested on MediaWiki 1.35 old legacy version with long-term support (September 2023) This version is recommend for use on MediaWiki 1.29< 1.35

History

The first version of this extension (1.x) was based on Group Based Access Control , but without bugs the original had.

• Version 4.0 is obsolete (phab:T281848). Upgrade recommend.
• Version 3.0.1 was tested on MediaWiki 1.34.0, but is obsolete. Upgrade recommend.
• Version 2.5.1 was tested on MediaWiki 1.33.0-alpha (5eb97ec)
• Version 2.6 was tested on MediaWiki 1.27.0-rc.0 (57f722a)
• Version 2.5 was tested on MediaWiki 1.27.0 (from git repository)
• Version 2.5 was tested on MediaWiki 1.22.9 (from git repository)
• Version 2.3 was tested on MediaWiki 1.22.0 (from git repository)
• Version 2.2 was tested on MediaWiki 1.22.0 (from git repository)
• Version 2.0 was tested on MediaWiki 1.19-alpha (from SVN repository)
• Version 1.2 was tested on MediaWiki 1.15.5-1 (from Debian repository)
• Version 1.1 was tested on MediaWiki 1.16.0(b3). Works fine, except that it needed a minor change to line 358 of AccessControl.php (remove '&' from parameter to function controlEditAccess()). When viewing a page on a Linux server, the ‎<accesscontrol> tags show. But on a Windows server, the tags don't show and it is fine! Still haven't figured that one out, but it is ok for my application.
• Version 1.1 was tested on MediaWiki 1.15
• Version 1.0 of this extension has been tested and works fine on MediaWiki > 1.12.x.
• Version 1.1 tested on MediaWiki 1.16.1 with new patch from http://git.felk.cvut.cz/pub/git?p=accesscontrol.git;a=commitdiff;h=2f678deed0e4e4f77620e391c94559c7b50102a9

આ પણ જુઓ

• Manual:Preventing access
• Extension:Semantic ACL
• PageOwnership - Multi-layered permission manager, whole wiki or specific pages, with friendly interface

Notes