|If you need per-page or partial page access restrictions, you are advised to install an appropriate content management package. MediaWiki was not written to provide per-page access restrictions, and almost all hacks or patches promising to add them will likely have flaws somewhere, which could lead to exposure of confidential data. We are not responsible for anything being leaked, leading to loss of funds or one's job.
For further details, see Security issues with authorization extensions
Release status: stable
|Implementation||User rights, Tag|
|Description||Extension to restrict access to specific pages based on internal groups or group lists from userspace. Git repository on server http://git.felk.cvut.cz/pub/git|
|Author(s)||Aleš Kapica (Wanttalk)|
|Latest version||2.3 tested on 1.22.0 (2014-01-10)|
|MediaWiki||mediawiki 1.16 <= accesscontrol 1.3
mediawiki 1.18+ - 1.20.x = accesscontrol v. 2.1
mediawiki 1.21 >= accesscontrol 2.2
|Example||http://support.dce.felk.cvut.cz/mediawiki/index.php/Support or https://www.thewoodcraft.org/wiki/index.php/thewoodcraft.org|
Translate the AccessControl extension if possible
|Check usage and version matrix; code metrics|
|Bugs: list open list all report|
This extension is based on original Extension:Group Based Access Control but without its bugs. Unlike the original double commas aren't used for selection group, only one comma is required. It is not necessary to use the ',,' separator at the end of the element content. It is also possible to use usergroups and internal groups MediaWiki at the same time.
- 1 How this extension meets the requirements for site security?
- 2 Features
- 3 Documentation
- 4 Attention
- 5 Example
- 6 MediaWiki Version
- 7 See also
- 8 Notes
How this extension meets the requirements for site security?[edit | edit source]
More info about potential problem of security is on page Security issues with authorization extensions. The following points based of the table on this page.
- Atom/RSS feeds & Diff & revision links
- Page content is protected, but when opening the page in the history of a piece of raw content will appear in this. If tag accesscontrol was placed at the beginning, a potential attacker may be to obtain information about names of the access lists of users!
- Listings & search
- If use search uknown or unauthorized user, and search result found in MediaWiki a page with protected content, it is this user redirected away.
- Inclusion/transclusion & related rights and other extensions
- We use AccessControl with extension DynamicPageList. The every page, which has content protected the by AccessControl - is secured, because the content page was controlled before finishing parsing in raw form code.
- The problem with redirection was be repaired in version 1.1
- API and action links
- Each anonymous user has automatically set to false all the action, besides view for a unprotected pages. Allowed actions for the authorized user depends on the permissions settings mediawiki and his username listed in the access list which pages will use.
- Edit Section and Watching Pages
- Options are available only to registered user. If user is logged and member from the security access list.
- Files & Images
- WARNING: The extension AccessControl does not protecting files against direct access via URL! If files can not be publicly available, must be protect at the server level!
- XML export (Special page Export)
- WARNING: AccessControl version < 2.0, was based on the hook, which was not protected from MediaWiki side before exporting in a raw form code the page. Therefore, if you use version AccessControl < 2.0, you must prohibit the special page for export the pages from MediaWiki.
- Author backdoor
- Extension AccessControl have not any backdoor!
- I recommend to turn off caching. See the previous paragraphs
Features[edit | edit source]
- easy to setup and simple to use
- no patches, real extension
- unlimited number of 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 may be protected by another extension or by this extension only
- In original Group Based Access Control can be set special namespace "Usergroup:.." only in extension variable
- namespaces may be protected by another extension or by this extension only
- mediaWiki sysop-Group may view and edit the protected pages
- controlled by extension variable
- access may be granted to multiple groups
- may be used for access control for internal system groups from MediaWiki in parallel with user groups lists
- read only access may be granted to for groups and for individual users
- Unauthorized user can't use search feature to find pages protected by accesscontrol element
Please read about security issues with authorization extensions
Documentation[edit | edit source]
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/AccessControl.git
Installation[edit | edit source]
Step 1: Local Settings File[edit | edit source]
- add the following lines to the bottom of your LocalSettings.php:
- add a namespace to the LocalSettings.php file for the purpose of creating groups.
- See Manual:Using_custom_namespaces for more information.
NB : See discussion
- Check (and maybe edit) the settings in AccessControl.php:
$wgAccessControlMessages = false; // if set to true, 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
Step 2: Create User Groups[edit | edit source]
User groups are simply standard wiki pages that are part of a namespace other than the default namespace. For ease of use, it is suggested that a specific custom namespace be created for the explicit purpose of managing access control list pages.
- Create a Wiki-Page with a users list in any namespace
- It is not sufficient to simply create a page with a colon (:) in the name, this extension requires the use of a namespace and one or more pages within namespaces
- Page Name Example: My:Group
- The namespace is My
- The group page is Group
- This is the name of usergroup
- Users are added to the group in a bulletlist
- Page Content Example
- Presume that the namespace IT exists
- Create a page in the namespace titled "Department"
- Create users "John Doe" and "Jane Doe" in the group. The group information is contained on the page "Department".
- Each user name appears as a list item.
*John Doe *Jane Doe (ro)
- User from a group, which have appended string "(ro)" to the name can only read protected Article, but can't edit it. For other group of users you can create memberlist with name Department too, but in other namespace.
- To protect namespace IT you can use for example Extension:Lockdown, but you can use element accesscontrol to protect it itself.
Step 3: Additional Access Control[edit | edit source]
- It depends on localization, your MediaWiki needs pages created to which anonymous or unauthorized users will be redirected. You have create them in advance, because some of them can't access pages from another page.
- The safety of the page provides accesscontrol element. And his content. If there isn't any or is empty the page is free accessible for logged users (they can read and edit page). No logged or annonymous user can only read the page.
- Members from groups in accesscontrol element can edit page, only if the group title in list doesn't have added string "(ro)", or if they don't have set readonly access in their user grouplist.
- If it is set the variable
$wgUseMediaWikiGroupsto true, you can use for managing access the internal groups from MediaWiki too.
- If it is set the variable
$wgAllowUserListto false, only members from 'sysop' group can edit usergroups pages in any namespace.
- In this example all users from the groups "Administrators", "IT:Department" and "Sales" can read the page but only the users from "Administrators" MediaWiki group (if exists) and John Doe from "IT:Deparment" usergroup can edit it.
Usage on Pages to Control Access[edit | edit source]
That is for the installation. To restrict access on a page for specific usergroups, just include the names of the allowed usergroups (separated by commas) as the content of accesscontrol tag in the body of that page. Thus, if you wanted to restrict access to the people with groups "Administrators", "IT:Department" and "Sales", you would use the following syntax:
IT:Department is usergroup, and groups Administrators and Sales may be added by Extension:GroupPermissionsManager. Members from group Sales page can read only.
- If it is set true
$wgAccessControlMessagesvariable, the element accesscontrol is replaced by warning message.
Attention[edit | edit source]
For version <= 1.3[edit | edit source]
|MediaWiki version:||≤ 1.17|
- Groups from MediaWiki must be in not localized form! In ex. 'sysop' not 'Správce' , etc.
- On page may be more accesscontrol elements. Access is accepted for groups from all.tags
- Anonymous user has not access on pages protected by accesscontrol elements
- Pages without protection can anonymous user only read
- Logged user has access on protected page only when he is member of any group with access rights on page
- If is set in extension script variable
$wgAdminCanReadAllon true, have members from group 'sysop' edit access on page always
For version >= 2.0[edit | edit source]
|MediaWiki versions:||1.18 – 1.20|
- From version 2.0 extension not use groups from wiki (without sysop), only groups created by users access lists!
- On page may be accepted only one accesscontrol elements.
- If the user is a member of multiple groups, so that takes precedence, which gives greater rights him.
|Warning:||Mediawiki >= 1.21 contains new framework ContentHandler and this extension version 2.1 is unusable. Use AccessControl version 2.2 which is updated for mediawiki 1.21 and above.|
For version < 2.3[edit | edit source]
- There was problem in function fromTemplate(), it caused that the extension AccessControl did not accept tags from included pages or templates.
Example[edit | edit source]
See an example of this add-on in action at: http://support.dce.felk.cvut.cz/mediawiki/index.php/Support run by the author)
Unfortunately the main page does not have an English version, which make it difficult to see the extension in action (for English speakers).
MediaWiki Version[edit | edit source]
- Version 2.3 was tested on MediaWiki version 1.22.0 (from git repository)
- Version 2.2 was tested on MediaWiki version 1.22.0 (from git repository)
- Version 2.0 was tested on MediaWiki version 1.19-alpha (from svn repository)
- Version 1.2 was tested on MediaWiki version 1.15.5-1 (from Debian repository)
- Version 1.1 was tested on MediaWiki version 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 version 1.15
- Version 1.0 of this extension has been tested and works fine on MediaWiki versions > 1.12.x.
- Version 1.1 tested on MediaWiki version 1.16.1 with new patch from http://git.felk.cvut.cz/pub/git?p=accesscontrol.git;a=commitdiff;h=2f678deed0e4e4f77620e391c94559c7b50102a9
See also[edit | edit source]
- Extension:Improved Access Control
- Extension:Page access restriction
- AccessControl extension read only feature error
- Manual:Preventing access
Notes[edit | edit source]
- As of version 2.0, it only works with ACLs stored in namespace (Main). It also can only protect pages that are in namespace (Main). Changes need to be made to getUsersFromPages and getContentPage to correct the behavior. Click here to see a patched version of the extension that is compatible with NameSpaces.
- 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. All though this isn't really a bug, it is undesirable behavior. Click here for an example showing a work around.