AccessControl

The MediaWiki software for the projects of the Wikimedia Foundation was not planned as a sophisticated CMS system.

AccessControl, developed since September 2009, this solved. And this page is meaned as manual for version 3.0

• "AccessControl" allows for both publicly accessible content and private pages to exist within a single "MediaWiki" instance. This manual provides instructions on how to maintain both public and private content within a single page.
• "AccessControl" allows content authors to decide who will have the ability to edit the content on the pages they are working on. This page protection can be easily turned on or off at any time.
• Even though "AccessControl" is based on page content control, it does not increase the load on the web server in terms of performance. Quite the opposite. It checks the page content before processing it into HTML and sending it to the client's web browser. If a user does not have access to a protected page, they are immediately redirected.
• "AccessControl" is programmed in such a way that it is impossible to obtain the content of a protected page by any currently known method, allowing the wiki to contain confidential content. It can also handle situations for which standard "MediaWiki" does not have any other security mechanisms.
• Protected pages, in combination with other features offered by "MediaWiki" and its extensions, can be used as an excellent means of private communication, where the user decides what to follow and how to be informed about updates.

Who uses "AccessControl"?

If you are interested in which versions of the "AccessControl" extension are being used and where, check out WikiApiary.

If you feel that there are too few websites listed there, keep in mind that "AccessControl" is primarily used by wikis that are not as open as Wikimedia Foundation projects. They usually do not have publicly available APIs and often restrict access to special pages through which configuration data can be obtained.

If a wiki registered on WikiApiary uses "AccessControl" and has an invalid link on a page from which the bot mines data, nothing will be discovered about its configuration either, because the bot will end up on a page with a message stating that anonymous users have restricted access.

The reliability of the "AccessControl" extension is evidenced by the fact that during its entire period of real-world deployment on the DCE FEL ČVUT wiki, there has not been a single case of page vandalism or misuse (or leakage) of protected content.

Please read this manual thoroughly. It's important to know how the AccessControl works, to be ready solve a situation when the someone make any mistake or tries to exploit any template to deny public access of your wiki.

If you are satisfied with how the "AccessControl" extension works on your wiki, you can in return support TheWoodcraft.Org. It is a wiki where version 3.0 was developed and is funded by its author.

Basic Configuration of MediaWiki Before Installing the AccessControl Extension

MediaWiki, the software on which Wikipedia runs, was created to help bring to life the previously utopian idea that high-quality web content can be produced through the collaboration of all users, including anonymous ones. However, due to its permissive approach, it soon became a popular target for psychopaths and frustrated individuals whose greatest joy is to cause harm. Therefore, user groups with various permissions and bureaucratic mechanisms for granting these permissions were introduced.

Standard "MediaWiki" primarily works with the following groups:

anonymous user

Every user who is not logged in and is identified by his IP address.

logged in user ('user')

This group contains every registered and logged in user identified by its username.

administrator ('sysop')

User who is in this group can perform activities necessary to maintain the wiki (for example, delete pages, return changes, etc.). It can be included in this group permanently, or temporarily.

bureaucrat ('bureaucrat')

Only users that belong to this group can grant rights to other users.

'bot'

It is a group reserved for users who frequently edit wiki content or perform bulk operations using various scripts. Some operations by users in this group are not logged to avoid unnecessary system load on "MediaWiki" and to ensure their actions are carried out as quickly as possible. Without this, other undesirable changes could go unnoticed on the Special:Recentchanges page. There are other groups that are creating by some extensions for their needs. However, it is always true that all members have the same rights within the group. If you want to have content in MediaWiki that is available to the public as well as content reserved for a select group of users, you will find that the user rights system based on group membership is not sufficient.

If "MediaWiki" does not have the "AccessControl" extension installed, the only way to prevent the display of page content is to allow access to the selected namespace only for a specific group of users and to deny access to all others as a precaution. This is an unfortunate solution:

• An anonymous user does not belong to any group to which rules can be applied, so all content in the wiki (or the reserved namespace) would have to be restricted to logged-in users with an assigned group. Otherwise, no one else would be able to access it. However, there are methods by which non-public content can be accessed in a wiki that does not use "AccessControl".

In the long run, this is useless because sooner or later, no one will contribute to the wiki or its reserved namespace, which only a limited group of users can access.

• Most users are not interested in dedicating their time to creating content that cannot be publicly presented. And content that cannot be accessed has zero informational value for others – it's as if it doesn't exist at all.

• Gradually, even those who called for the closure of such pages will stop visiting them because they will lack content that interests them and gives them a reason to return. A wiki without content loses its purpose.

• • A wiki is a living organism**, given meaning by the general sharing of the information it contains. **Everyone** (including anonymous users) **should have the opportunity to read its content**, unless restricted by the license or the operator's terms of service. And if a user meets the conditions required for registering a user account, they should also have the opportunity – as a logged-in user – to participate in content creation.

Therefore, the first line in the configuration file LocalSettings.php allows the action 'view' for all users – including anonymous ones. The other lines preventively prohibit actions that would allow users to write to your wiki anonymously:

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

With this setup, only registered and properly logged-in users will have access to editing pages in your "MediaWiki" instance – this is the basic requirement for the "AccessControl" extension to function as intended.

If you feel this is too restrictive for anonymous visitors, consider that **your wiki will likely never have enough vigilant administrators** to promptly remove undesirable changes made by vandals! And only **you are responsible for the trustworthiness of your "MediaWiki" instance and you guarantee the quality of its content with your name**. Therefore, for small wikis, the following premise always applies:

The ability for a user to contribute to content creation is not a right, but a privilege!

Additional Recommended Settings for LocalSettings.php

The "AccessControl" extension is primarily intended to protect content and does not address access to special "MediaWiki" pages. However, there is no reason for an anonymous user to have access to most of them.

Therefore, I recommend restricting access to special pages. There is a "MediaWiki" extension for this, DisableSpecialPages, but it has been unmaintained for a long time. If you prefer, you can use the same code in your LocalSettings.php configuration file as used on the TheWoodcraft.org wiki.:

 …
 function disableSomeSpecialPages(&$list) {
     global $wgUser;
     if ( is_array( $wgUser->mRights ) && in_array( 'createpage', $wgUser->mRights ) ) {
         return true;
     } else {
         if ($wgUser->mId > 0 ) {
             return true;
         }
         unset($list['Mypage']);
         foreach( array(
             'Activeusers',
             'Allmessages',
             'Allpages',
             'Ancientpages',
             'ApiSandbox',
             'Blankpage',
             'BlockList',
             'Boilerplates',
             'Booksources',
             'BrokenRedirects',
             'CategoryTree',
             'ComparePages',
             'Contributions',
             'CreateCategory',
             'CreateClass',
             'CreateForm',
             'CreateTemplate',
             'Deadendpages',
             'DoubleRedirects',
             'ExpandTemplates',
             'Export',
             'ExportTranslations',
             'Fewestrevisions',
             'FileDuplicateSearch',
             'Forms',
             'FormEdit',
             'FormStart',
             'LanguageStats',
             'LinkSearch',
             'ListDuplicatedFiles',
             'Listfiles',
             'Listgrouprights',
             'Listredirects',
             'Listusers',
             'Log',
             'Lonelypages',
             'Longpages',
             'ManageMessageGroups',
             'MediaStatistics',
             'MessageGroupStats',
             'MIMEsearch',
             'Mostcategories',
             'Mostimages',
             'Mostinterwikis',
             'Mostlinked',
             'Mostlinkedcategories',
             'Mostlinkedtemplates',
             'Mostrevisions',
             'Movepage',
             'MultiPageEdit',
             'Newimages',
             'Newpages',
             'PagesWithProp',
             'PagesWithoutScans',
             'PageTranslation',
             'Preferences',
             'Prefixindex',
             'Protectedpages',
             'Protectedtitles',
             'RandomInCategory',
             'Randompage',
             'Randomredirect',
             'Redirect',
             'ResetTokens',
             'RunQuery',
             'SearchTranslations',
             'Shortpages',
             'Statistics',
             'SupportedLanguages',
             'TrackingCategories',
             'Translate',
             'Translations',
             'TranslationStats',
             'TranslationStash',
             'Uncategorizedcategories',
             'Uncategorizedimages',
             'Uncategorizedpages',
             'Uncategorizedtemplates',
             'Unusedimages',
             'Unusedtemplates',
             'Wantedfiles',
             'Wantedpages',
             'Wantedtemplates',
             'Watchlist',
             'Withoutinterwiki'
             ) as $i ) {
             unset( $list[$i] );
         }
     }
     return true;
 }
 $wgHooks['SpecialPage_initList'][]='disableSomeSpecialPages';
 …

Extended Rights Specific to Selected Extensions

Certain rights added to your "MediaWiki" by some extensions can potentially create security "holes" due to their default settings, through which an unauthorized user might gain access to protected content – for example, the Translate extension. If you use such an extension, check if it allows anonymous users to extract any content from your wiki. If it does, restrict its rights for anonymous users as a precaution.

For the TheWoodcraft.org wiki, it was necessary to set these variables:

 // Extension:LookupUser
 $wgGroupPermissions['*']['lookupuser'] = false;

 // Extension:Translate
 $wgGroupPermissions['*']['pagetranslation'] = false;

Installation

Installing AccessControl is very simple:

1. Clone the source code from the git repository, or unpack from the downloaded tarball, into the $ path directory of your instance MediaWiki .
2. Then add the following lines to the LocalSettings.php configuration file::

wfLoadExtension( 'AccessControl' )

Once you have saved the LocalSettings.php file, your wiki will start using the extension AccessControl. Please check you Special:Version page.

How does AccessControl work with MediaWiki

AccessControl checks the content on the server side - before the MediaWiki parser generates HTML code that will be delivered to the client's web browser. If, during a AccessControl check, it encounters a code that tells him that the page content is protected, it checks to see if the user who sent the request can access the content.

editors

have full rights to all operations

visitors

only have the right to read content

For users who cannot read the content even as (visitors), AccessControl stops the page's processing, and returns the warning page HTML code thus the user cannot have access to the content of the requested page.

How does AccessControl know whether it's a protected page?

There are three possible ways AccessControl to tell you that a page is protected:

1. Template Parameter
2. Named Used Template
3. Using accesscontrol

On one page, you can use a variety of ways to pass on AccessControl to who can drop on the page, but the extension will have the last word!' . You can take advantage of this if you want content for different user groups and public content within a single page. It is recommended that you use the template instead of the $ tag používat šablonu.

Templates and their parameters

A key role in "MediaWiki" is played by transclusion. This mechanism allows the content from one page to be embedded into another page. Most commonly, pages from the Template namespace (Template) are transcluded, and additional arguments can be passed to them to modify the wiki code generated based on their content.

The separator for arguments passed to a template is the pipe symbol |. The first argument is always the name of the page (template) whose content is to be processed, and it may be followed by additional arguments.

{{template | A | B | C }‌}

The arguments are processed sequentially.

{‌{template | 1 = A | 2 = B | 3 = C }‌}

And they can also be numbered or named.

{‌{template | first = A | second = B | etc = C }‌}

If they are numbered or named, they can be passed in any order.

{‌{template | 2 = B | 3 = C | 1 = A }‌}

If a template does not work with a named or numbered argument, it ignores the passed value. This means it does not appear in the resulting HTML code of the page, and "AccessControl" takes advantage of this.

Difference between parameter and attribute

This is not an attribute identified by a parameter!

{‌{template | e‌‌ditAllowedUsers TestUser }‌}

This is a parameter. The parameter is followed by the symbol = and then a list of usernames or user groups.

{‌{template | e‌ditAllowedUsers = TestUser }‌}

Page Protection by Template Parameter

 

• Make sure that someone does not abuse any of the parameters with which AccessControl works with some well used template!

If a vandla puts a parameter in one of the widely used templates, and AccessControl evaluates as a page protection, no one else can access page that are using this template anymore! - even administrators if the global variable $ 1 is $ 2.

Therefore, as a precaution, you should prevent all templates from being zamykat

If a user intentionally does something like that, you should block it uncompromisingly so that it can no longer harm.

• Also be careful when writing names - parameters, pages and users.

Just make a typo mistake, missed letter, or replace small letter with big or vice versa and AccessControl protection won't work!

You and basic wiki users can avoid this by using the Page Form extension and managing user lists via forms.

AccessControl works with the page code before processing the template. So, if it finds any of the following parameters in the attributes of any template, it knows it will contain information through which it will obtain a list of users to work with further.

isProtectedBy – list of user groups

readOnlyAllowedGroups – user groups with read-only access only

editAllowedGroups – users groups with the right to edit

readOnlyAllowedUsers – a list of users that can only read the content of the page

editAllowedUsers – list of users who has the right to edit

All the parameters listed can be used at the same time within the same template. The indentation indicates what hierarchical position they have in relation to each other. You will find out more in the description of each parameter, with examples below :

editAllowedUsers

By using this parameter, an ordinary template becomes seznam uživatelů. Any 'user' whose name will be listed 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 isProtectedBy. If more than one user is listed, their usernames should be separated by a comma.

…
| e‌ditAllowedUsers = Kili, Quido
…

isProtectedBy

Through this parameter, it gets a AccessControl list of wiki pages from which it attempts to extract information about who and what type of access is allowed to the page. If a user name appears in this list, it searches AccessControl for the default namespaces and most likely encounters a user page from which it will attempt to retrieve the list of users. While this is of course possible, 'I do not recommend' use user lists for user pages!

As a list is automatically protected by the AccessControl since version ?, so no one else can read it. If you prefer, use a page from the main namespace or subpage to list the users to protect other pages. This would make the accesslist user's TestUser user sub-page look different with a user group.

…
| isProtectBy = TestUser/accesslist
…

The original page protection solution, using the <a‌ccescontrol> tag, worked with the fact that the content of the tag is a string in which it can occur as specific usernames as well as page names whose content can be interpreted as a list of users. In the same way, the content of the first template attribute that has the accesscontrol string in the name is accessed because it is only an alternative to the <a‌ccescontrol> based template tag.

readOnlyAllowedGroups

This parameter has greater weight than isProtectedBy. It also accepts only a list of user groups. However, all users from these groups will have the right to only read the page where the template with this parameter is inserted. This is regardless of whether they have editing rights or only reading rights in the user lists passed through the isProtectedBy parameter.

Therefore, the template with this parameter should also use the editAllowedUsers parameter, at least with the name of the page editor. Otherwise, no one except the administrator will be able to access it.

editAllowedGroups

This parameter also accepts only lists of user groups. Unlike users from the list in the readOnlyAllowedGroups parameter, users from these groups have the right to edit the page. This is regardless of their default rights within the groups passed by the isProtectedBy parameter and even if they are listed in a group that only has rights to read content.

…
| isProtectBy = test-user
| r‌eadOnlyAllowedGroups = groupB
| e‌ditAllowedGroups = groupA
…

If, in the scenario demonstrated by the above code, a user is in both the groupB group, which only has reading rights, and the groupA group, their editing right will take precedence!

readOnlyAllowedUsers

On the other hand, it is useful if we have the option of banning a user from a group that has the right to edit the page. And that's what this parameter is for. If AccessControl finds the name of a user in it, it grants him only a read-only access. Regardless of whether the edit right is set within a group passed by isProtectedBy or editAllowedGroups.

Further template processing

If AccessControl evaluates based on the content of the parameters provided that you, as a user, have access to the page allowed, these parameters can continue to be processed in the used template.

{‌{Template a‌ccesscontrol
| Tahle stránka žádný externí seznam nepoužívá, protože se chrání sama
| e‌ditAllowedUsers = TestUser
| Tohle je seznam uživatelů podle verze 3.0
}‌}

Even though the template contains the string 'accesscontrol' in its name, the content of the editAllowedUsers parameter is processed instead of being the first attribute, because template parameters have higher priority. Therefore, only a single user TestUser could access the page where this template appears in this form. No one else would be able to access it.

Page Protection Using Tags

Support for the <a‌ccesscontrol> tag was included in version 3.0 only to gradually replace the original page protection and avoid the need to change the content of existing pages. Do not use it for new pages! If you encounter it on any page, replace it with a template.

Older versions of the AccessControl extension used only the paired tag <a‌ccesscontrol> to protect pages.

If you use a paired tag <a‌ccesscontrol> with your username instead of a template on a page, you will have access to such a page only. The inserted code will look similar to the following example. Just replace Username with your username.

<a‌‌ccesscontrol>Username</a‌ccesscontrol>

If you want more users to have access to this page, you have two options. Either you can add their usernames, as in the following example.

<a‌ccesscontrol>Vaše uživatelské jméno, TestUser, Další uživatel</a‌ccesscontrol>

Or you can use a list of users. If you create such a list on the test-page page, it will look like this:

<a‌ccesscontrol>test-page</a‌ccesscontrol>

Using a list is advantageous when the same group of users works with a larger number of protected pages.

Protection by the Content of the First Template Parameter

A page protected by a template with the string accesscontrol in the name cannot be used as a list of users to protect other pages!

Protecting pages using the <a‌ccesscontrol> tag has one major disadvantage – protected pages are difficult to find. On the contrary, a page that uses a template can be easily found using the following procedure:

1. Search for the template name on the page Special:Templates (if the template exists) or Special:Wantedtemplates (if the template does not yet exist) and click on it.
2. If you are a logged-in user, you will also be redirected to the editing page of the non-existent template (an anonymous user is automatically redirected away in such a case).
3. Notice the link What links here in the menu on the left. It leads to the special page Special:Whatlinkshere.
4. If you click on it, it will immediately generate a list of pages that use this template. If you have access to them, you can easily navigate to them through these links. If not, it redirects you away.

Therefore, an alternative was included in the new version of the AccessControl extension 3.0, which allows gradually replacing the <a‌ccesscontrol> tag, which was necessary in previous versions, with a template.

You can name this template whatever you want; the important thing is that it contains the string a‌ccesscontrol in its name. If you pass it as the first parameter, the original content of the <a‌ccesscontrol> tag (a list of users or user groups separated by commas), it will work the same way, but you can also add additional parameters that the template can process if the user has access to the page.

For "AccessControl," it doesn't matter at all whether this template exists or not. So, if you use the following wiki code on the test page test-page instead of the tag or parameterized template, replacing the string Username with your username, the page protection will work exactly the same as if you had used the <a‌ccesscontrol> tag.

{‌{Template accesscontrol|Username}‌}

If the template Template a‌ccesscontrol does not exist, only a red link to the non-existent page will be displayed instead. However, you are free to create this template and use its content. When you click on this link, you can enter the following code into the template content. Under no circumstances should you copy it! as it contains hidden characters, so it would not work:

Page {‌{PAGENAME}‌} is protected by AccessControl.
Access is allowed for: {‌{‌{1|}‌}‌}
‌{‌{2|}‌}‌}

When you return to the test page test-page, protected by such a named template, and refresh it, instead of a link to a non-existent template, you will see text followed by a list of users and groups that will have access to the page.

Then log out and try to see if AccessControl displays the page even if you try to access it anonymously. If you can access the page as an anonymous user, it means you have misconfigured something somewhere.

If you are unable to access it even as a logged-in user, it's possible that you entered an invalid username or group name - in that case, you'll need to ask for help from a user who is a member of the 'sysop' group to correct your mistake.

You can also try out how it will look when you pass additional parameters to the template used on the page test-page:

{‌{Template accesscontrol
| Username, test-page, TestUser, Čtenáři (ro)
| Next content in the second attribute 
| Other atributes…
}‌}

As you can see for yourself, using a template opens up further possibilities.

If, however, you use a named parameter in any of the attributes, which AccessControl works with, its processing will take precedence!

How does the check work?

This manual is prepared so that you can import it into your wiki and gradually try out (and test) through this page all possible combinations and ways of protecting the page. The default assumption is that you will create a test page test-page for this purpose, which you will work with.

If you leave the configuration variable $wgAccessControlNamespaces untouched, AccessControl will, during the check of the protected page, proceed as follows if it encounters an item that can be interpreted as an element intended for page protection, which contains the string test-page:

1. It will check whether test-page is not accidentally a username.
2. Then it will check if there happens to be a page named like that in the main namespace. If so, it will try to extract a list of users from it.
3. Then it will check if such a page happens to exist in the namespace reserved for user pages test-page. Surely you have realized by now that in such a case, there would have to be a user named test-page. If such a user existed and had code on their user page that could be interpreted as a list of users, then AccessControl will use it.

The result will be an array containing two keys: "editors" and "visitors". AccessControl will check this array, and if it finds your username in it, it will continue processing the page.

In the new syntax based on template parameters, the person setting access rights to the page can ensure that AccessControl does not delay by searching through all namespaces set in the variable $wgAccessControlNamespaces.

Simply provide the name in parameter isProtectedBy, readOnlyAllowedGroups, or editAllowedGroups, specifying the page name with the user list, including the namespace. So instead of their username, user TestUser would write the appropriate name into parameter User:TestUser. This will naturally shorten the processing of the protected page.

For anonymous users, MediaWiki typically uses the IP address from which they access the page as their name. Theoretically, it would be possible to allow access to an anonymous user based on their IP address. However, I haven't tried it in practice yet.

Global Configuration Variables

In the configuration file LocalSettings.php, you can use the following global variables with the AccessControl extension version 3.x:

$wgAccessControlRedirect

By default, this variable is set to true. If a user does not have permission to access the content of a page protected by AccessControl, they are automatically redirected to the MediaWiki:Deny_user page, where a (localized) notification is displayed, indicating that they attempted to access a protected page without permission. This automatic redirection can be disabled by setting the variable $wgAccessControlRedirect to the value false:

$wgAccessControlRedirect = false;

Even though redirection can be turned off, only disable it when necessary. Automatic redirection is not used to protect the page.

• Even with redirection turned off, unauthorized users will not gain access to the protected content.
• Redirection saves time and server resources.
• It's unnecessary for the server to continue processing the content of the page if it's clear that the user will not have access to the page. An anonymous user "by default" only has the right to read the content of publicly accessible pages. They have no business on pages protected by AccessControl.
• It is also unnecessary to continue processing the content of the page if it is clear that the user, despite being properly logged in, does not have access to its content (i.e., does not have reading rights).

If AccessControl determines that the user does not have access to the page, it interrupts further processing of the original page and immediately redirects to the MediaWiki:Deny_user page, which should contain only a brief message stating that the user attempted to open a protected page. This is the fastest operation for the wiki since the content of this page does not change. It is the final stop for various bots, nuisances, and intruders. Therefore, only disable redirection when absolutely necessary.

You can temporarily disable redirection if you're interested in how quickly the page content is processed or if you need to see the control messages generated as comments in the HTML code. If you don't disable redirection, you will only see what pertains to the processing of the target page MediaWiki:Deny_user.

$wgAdminCanReadAll

AccessControl is programmed so that users with administrative rights (the 'sysop' group) can assist users who, due to an error in the user list settings, have been cut off from their own page. Therefore, the default value of this variable is true.

However, such a lenient approach may not suit everyone, especially if their wiki contains content that should only be accessible to selected users. Therefore, there is an option to disable this privileged status of administrators through a setting.

$wgAdminCanReadAll = false;

$wgAccessToHistory

It is up to you whether you allow anonymous users to view the page history or not. Personally, I believe that viewing the page history and changes to the wiki code should be a privilege of logged-in users. Therefore, the default setting is false.

Through the history, a user can view the diff files. This is useful if we want to allow users to get an idea of the changes that have occurred on the page over time. However, under certain circumstances, displaying diff files could compromise the content of a protected page.

Therefore, if you want to allow anonymous users to view the history, perform thorough tests on your MediaWiki to ensure that this does not lead to compromising protected content. You can enable the display of history and diff files by setting:

$wgAccessToHistory = false;

Whether this wiki allows viewing the history or not can be checked by clicking on this link. If history viewing is disabled for anonymous users, you won't see anything as an anonymous user, and you might be directly redirected to the MediaWiki:Deny user page.

$wgAccessControlNamespaces

Originally, AccessControl searched for user lists only on pages in the main namespace. The new version 3.x assumes that pages containing user lists can also be located elsewhere.

This variable primarily exists so that it is not necessary to always write the page name with the user list, including the namespace in which it is located. The global variable $wgAccessControlNamespaces is an array with numerical identifiers of the namespaces in which AccessControl will sequentially try to find the user list identified by the page name if it is not specified along with the namespace name.

When writing the namespace name, errors can easily occur, especially because MediaWiki tends to replace canonical names with localized versions. AccessControl accepts both, but I recommend preferring the canonical name over the localized version. So, instead of Uživatel:, use User:.

By default, the namespaces listed below are used. However, you can set different ones through LocalSetting.php. All of them will be checked sequentially.

0 - NS_MAIN the main namespace, from which pages are loaded if the namespace is not explicitly specified

12 - NS_USER the namespace for user pages; AccessControl assumes that everyone will want to maintain a list of users who will have access to their protected pages within their own user page.

User Lists

In the new version, any page that uses at least one parameter, based on which a user list can be obtained, can serve as a user list.

A protected page is automatically inaccessible to anonymous users. If you want to publish part of its content publicly, read how to have both public and private content on one page.

If you are just getting familiar with the AccessControl extension, do not make your first attempts at configuration as a user with administrative rights (the 'sysop' group) and do not disable redirection! This will protect you from your own carelessness and mistakes, as AccessControl will not allow you to save a page that you might not be able to access again. If something like this happens, read what to do if you can't access a page.

Managing Users and Groups via Form

From MediaWiki version 1.23+, parameterized templates can be edited through forms, thanks to the Page Forms extension.

Original User List Syntax

Uncategorized user lists in a wiki that used the old syntax could only be found through a specific username from the list. However, if the search string also appeared on a page the user did not have access to, they would not get the search results. This does not apply to AccessControl version 3.0, but even so, it is better to use a template instead of the <a‌ccesscontrol> tag to protect page content.

AccessControl version 3.0 has been fundamentally redesigned, but for backward compatibility, it also supports the original syntax for user lists that was used up to version ≤ 2.6.

This syntax uses a page as a user list where the name of each user who is to be a member of the group is placed on a line that starts with a bullet point (the '*' character). This is followed by a space and then the username.

For a test user with the name TestUser, the corresponding line looks like this:

* TestUser

If the user should only have read access to the content, add the string (ro) after their name:

* TestUser (ro)

A user list created this way is a regular wiki page, which is not protected in any way by itself.

AccessControl allows the page to protect itself. So, if you want to create and test such a list from the page test-page, its content should look like this, with the only difference being that instead of the test user's name TestUser, you use your username.

* TestUser
<a‌ccesscontrol>test-page</a‌ccesscontrol>
[‌[Category:AccessLists]‌]

Categorizing user lists of this type is necessary because they do not differ in content from regular wiki pages and, therefore, are not easily searchable afterward.

Locking a Page Using MediaWiki's Standard Mechanism

Surprisingly, it never occurred to some users of the AccessControl extension that a page could be protected by itself. They often tried to solve the protection of user lists in other, sometimes completely nonsensical ways.

However, there are situations where it is better to choose a different method of page protection than using AccessControl.

One of the tools MediaWiki uses to combat vandalism is page locking. However, this privilege is reserved for administrators, users from the 'sysop' group, who have the right to block page editing (block). If a user is not part of this group, they cannot protect a page in this way.

However, there are situations where it is better to restrict the ability to edit a page as a precaution. This is typically the case with templates. Through the misuse of a widely used template, the AccessControl extension can be exploited to deny access to all users. Therefore, it is advisable to lock ('protect') its content as a precaution. Its content will remain publicly accessible, but only those with administrative rights ('sysop') will be able to modify its code.

Ostatně, změny obsahu šablony by se měly testovat na jiné, testovací šabloně a teprve po jejich důkladném otestování kopírovat do šablony, která se již používá.

Placing the Page in a Reserved Namespace

In addition to standard namespaces, you can define your own namespaces within the configuration file LocalSettings.php. These can be used in many ways. Among other things, you can adjust access rights by setting the variable $wgNamespaceProtection, so that, for example, only selected user groups in MediaWiki have the right to edit pages in this namespace.

The following sample code demonstrates how you can create your own namespace NS_PRIVATE with ID 1234, in which only users with the assigned right userrights (which by default are only bureaucrats) can make changes:

define("NS_PRIVATE", 1234);
$wgExtraNamespaces = 
    array(NS_PRIVATE => "private"
    );
$wgNamespaceProtection[NS_PRIVATE] = array( 'userrights' );

If you want to restrict rights in this way for other, already existing namespaces, you only need to change the default settings for the namespace.

Tests

Everyone who wants to protect their pages using the AccessControl extension should know the ways in which protected MediaWiki content can be accessed if there is an error somewhere.

If you have imported this page into your own MediaWiki instance, you can use the links below for testing.

Create a page test-page and use it to try out how to set page protection, how to create a user list, how to work with it, and how to use it to protect other pages. It is important that you understand how it all works.

Make sure to set your name on the test-page page, otherwise, you might lock yourself out of the page. After completing the tests, I recommend deleting its content so that someone else can use it for testing.

When testing your pages, I recommend using two different web browsers. Access the page as a logged-in user through one browser, and simultaneously test anonymous access through the other.

If you want to find out what the AccessControl extension does during page processing, you can use the debug messages prepared in the code. You can recognize them by the fact that they are followed by a comment with the keyword DEBUG on the same line.

These messages output their content to the page using the printDebug() function. They are not visible on the page. You can access them only by looking at the HTML code of the page.

Be prepared for some messages to trigger a PHP error. You don't need to pay attention to it. The error will disappear after commenting out the debug output.

If you discover any additional methods not mentioned here that could potentially lead to the compromise of a page, don't hesitate to write in!

Search

Under normal circumstances, search will find the search string even on pages protected by AccessControl. However, if the user does not have the right to access the content of the page, a placeholder text will be displayed instead of the context. If they try to navigate to this page, they will be automatically redirected away.

Access to Wiki Code and Page History

If you do not change the default value of the configuration variable $wgAccessToHistory to true, an anonymous user will not be able to access the page history, even if it is not protected by the AccessControl extension. They will also not be able to access its wiki code.

The only change history where it is desirable to maintain access for anonymous users is on the Special:Recentchanges page (recent changes history). Links that allow viewing diff changes are either inactive, or when attempting to view the diff changes, users are redirected to the MediaWiki:Deny user page, unless redirection is disabled via the $wgAccessControlRedirect variable.

It is entirely up to you whether you choose to ease the default restrictive access or not. No one will be able to access the history and content of protected pages this way. However, repeatedly browsing the history and generating diff pages can unnecessarily burden your web server – this is why viewing page history, wiki code, and diff files is not enabled by default. If you are using AccessControl, you can safely allow access to the history. Once an intrusive bot encounters a protected page, it will be immediately redirected to the information page, which will stop further content browsing.

Can an Anonymous User View the Diff Changes?

You can find this out quickly and easily. This link leads to the diff file created during the last edit of the main page of this wiki.

1. A logged-in user should be able to view the differences without any problems
2. An anonymous user should be redirected away

If you're wondering how the revision ID of your main page got into this page, you've just stumbled upon the secret of magic words – Magic Words. The code that generated the previous link looks like this:

[[Special:Diff/{{REVISIONID:Main Page}}/next|this link, which displays the diff file for the latest edit of the main page of this wiki]]

Is Access to the Special Page Displaying Content Differences Allowed Here?

Since MediaWiki 1.23+, there is a special page available, through which you can view a color-coded output similar to what the diff utility returns, for any content revision.

If this page is available here, you can find out through this link: Special:Diff.

1. If access to the Special:Diff page is not restricted (see above, recommended configuration settings for LocalSettings.php), a form will appear where you can enter the ID of any revision.
2. If access to the Special:Diff page is restricted, an anonymous user will be redirected away, or MediaWiki will inform them that no such page exists.

Viewing the Wiki Code of a Page

Viewing the source code of a page is allowed for anonymous users only if the variable $wgAccessToHistory is set to true. Then you can use the following link format on pages, which will display the page's edit window with its wiki code to the anonymous user, but without the ability to edit the content.

If content editing is possible, you likely have a mistake in the configuration of the LocalSettings.php file.

Viewing the Wiki Code of the Unprotected Main Page

If you want to allow anonymous users to copy the content of your wiki pages to their own MediaWiki instance, you can help them by adding a link to the relevant page on your site in the following form:

https://www.thewoodcraft.org/wiki/index.php?title=Main_Page&action=edit

If viewing the history and code of unprotected pages is allowed, clicking this link will open an edit window with the page's wiki code (in read-only mode), from which they can copy the content.

Viewing a Specific Version of an Unprotected Page's Content

Linking to a specific older version of a page is also dependent on the setting of the variable $wgAccessToHistory. If you want to link to specific content revisions, its value must be true. When calling the page, you must also include the revision number:

https://www.thewoodcraft.org/wiki/index.php?title=Main_Page&oldid=104563

When calling a specific revision through the "oldid" parameter, the page name passed in the "title" parameter does not matter at all – the revision number is what matters.

How Do I Test That My Pages Are Protected by AccessControl?

The following series of tests assumes that you have already created a test page test-page in this wiki, where you have learned how to set up page protection. For the next test, the test-page page should be set to self-protect.

Direct Access

https://www.thewoodcraft.org/wiki/index.php/test-page

The authorized user will see the page. Everyone else will be redirected away.

Access via "view" action

https://www.thewoodcraft.org/wiki/index.php?title=test-page&action=view

The authorized user will see the page. Everyone else will be redirected away.

Access via "edit" action

https://www.thewoodcraft.org/wiki/index.php?title=test-page&action=edit

The authorized user will see the edit window with the page's wiki code. Everyone else will be redirected away.

Access via "history" action

https://www.thewoodcraft.org/wiki/index.php?title=test-page&action=history

The authorized user will see the history of the protected page. Everyone else will be redirected away.

Access to view revisions via "action" (view)

https://www.thewoodcraft.org/wiki/index.php?title=test-page&action=view&oldid=95418

The authorized user can browse the revision history. Everyone else will be redirected away.

Access to view page revisions via "direction"

https://www.thewoodcraft.org/wiki/index.php?title=test-page&direction=prev&oldid=95418

The authorized user can browse the revision history. Everyone else will be redirected away.

Access to view the diff page for the latest revision via "diff"

https://www.thewoodcraft.org/wiki/index.php?title=test-page&diff=prev&oldid=95418

The authorized user will see the current difference in the content of the test-page page from the latest revision. Everyone else will be redirected away.

Then repeat this set of tests while logged in as a user with the right to edit the test-page page.

And then repeat this set of tests again, but while logged in as a user who does not have the right to edit the content of the test-page page, but can read it.

I recommend trying this series of tests for the scenario where the self-protect setting of the test-page page is configured:

• using a parameterized template
• utilizing the old syntax and the <a‌ccesscontrol> tag
• using a template with the string accesscontrol in its name

Also, try to see what the results of these tests will be in a situation where the test-page page is protected through another page. Try:

• using a list located in the main namespace (identified only by the page name)
• using a list that will be located in another namespace, set in the variable $wgAccessControlNamespaces
• using a list that is specified in the template parameter, including the namespace name

Test Access to Protected Content via REDIRECT

Redirection is a basic MediaWiki functionality that allows access to a page through alternative titles. Essentially, it is a mechanism similar to transclusion, with the difference being that the content to which the target page refers is directly generated. In older versions of the AccessControl extension, it was possible to bypass page protection in this way.

Create a page with the following content and then test whether you can access the test-page page as an unauthorized user through it or not.

#REDIRECT [[test-page]]

Test Access to Protected Content via Transclusion

Embedding a Protected Page

If you embed a page that has content protected by AccessControl into another page, it should automatically inherit the same access rights as the embedded page. If it doesn't work this way, it is an error!

Embedding a page from the main namespace looks like this:

{‌{:test-page}‌}

If you are embedding a page from another namespace, you must specify its name. Although it is possible to use localized namespace names, whenever possible, use the canonical namespace name derived from English.

{‌{:User:TestUser}‌}

Embedding a Protected Template

Transcluding a protected template works (and looks) similarly to transcluding a page from the main namespace. The only difference is that if you do not use a colon before the page name test-page, the MediaWiki system will automatically assume that it is a page from the Template namespace:

{‌{test-page}‌}

If it is a template that is protected in some way by AccessControl, the page into which the template is embedded may behave differently.

Multiple Transclusions

Multiple transclusions can, under certain circumstances, lead to a situation where no one can access the page – not even an administrator ('sysop')! Unfortunately, there's nothing specific I can say about this because it happened to me only once during testing in development, so it's quite possible that the cause has long been resolved.

Nevertheless, multiple transclusions do work with protected pages, but I don't recommend it much. When chaining a larger number of protected pages, a small change in permissions on any intermediate page is enough to cut off a user (or an entire group).

Protected - Include - Include

Protected - Changed x Not access

Beware of the Labeled Section Transclusion Extension

Labeled Section Transclusion, combined with the DynamicPageList3 or SubPageList extension, is a great tool for creating templates that generate dynamic page content. But be careful of its misuse!

Misuse does not pose a threat from anonymous users, as they do not have the right to edit the page. The risk only comes from logged-in users.

However, it's not that simple. Essentially, it involves the misuse of the same mechanism used to manage both private and public content on a single page.

To access the protected content of the page, an attacker would need to know not only the name of the protected page but also the name of the unprotected section. Therefore, the likelihood of misuse is very low, but it still exists.

Carefully evaluate everyone who is interested in a user account on your wiki. Those who are genuinely interested in collaboration should understand your caution. After all, it is much better to be vigilant than to deal with extensive damage later.

Test to Determine if the Content of a Protected Page Can Be Obtained by Export

To facilitate content sharing, MediaWiki provides a special page Special:Export through which the content of a wiki page, including its history and embedded templates, can be exported to an XML file. This file can then be imported into another MediaWiki instance via the special page Special:Import.

It is a useful mechanism that allows the transfer of completed templates and manual pages. Unfortunately, for wikis with protected content, it poses a certain risk if every logged-in user has the right to export.

Even the protection in an older version of the AccessControl extension could be bypassed in this way. However, this is different with version 3.0.

• The page will be skipped if the user does not have access to it.
• If the user has read-only access, only the current version of the page will be exported.
• A complete export, including the change history, is accessible only to users with editing rights.

It is not necessary to address the import of a page, even though it is possible to change the content of a page by importing a modified file. However, the page would need to be deleted before the import. And for a user who could do this, changing the data in another, less complicated way would not be a problem.

Tips

Do not use templates in parameters processed by the AccessControl extension!

If you thought of using a template instead of a user name or user group, be aware that AccessControl works with the uninterpreted wiki code of the page, so it will attempt to evaluate the string of characters as a name rather than the result of transclusion, as you might expect. See the example:

<a‌ccesscontrol>{‌{‌{nobody}‌}‌}</a‌ccesscontrol>

In this specific case, AccessControl would attempt to find a user whose name matches the string ‌{{‌{nobody}}}, which is nonsensical. Such a user would certainly not exist. With a parameterized template, the result could be completely unpredictable, so I don't even dare to guess what AccessControl would try to find. What is certain is that it most likely won't exist, because MediaWiki does not accept such strings in the page name.

When a non-existent page (group) or invalid user name is listed as a list of users

If your wiki instance is set to be case-sensitive, it can easily happen that you accidentally write a user name or the name of a page with a group of users incorrectly. Simply substituting, adding, or omitting a single letter can cause problems.

If this happens to you, read what to do when you cannot access a page.

Do not blindly copy code from these pages!

• You can certainly use the sample wiki code from the examples on this page on your own wiki — and in some cases, it is even explicitly recommended. However, do not copy code from this page using the copy & paste method under any circumstances!. You would encounter an unpleasant surprise.

• To make this page publicly accessible even on wikis that use AccessControl, an invisible zero-width space (U+200C character ZERO WIDTH NON-JOINER &‌#8204;) was added to strings that would normally be evaluated by AccessControl as part of the page's protection. This is an unprintable character that you don't see, but from PHP's perspective, it is a regular character that prevents unwanted interpretation of strings, whether on the server side (parameters for AccessControl) or on the browser side (HTML entity).

If you were to copy a string with an invisible space, you would then futilely search for why the AccessControl extension isn't working as expected!

A page protected by a template with the string accesscontrol in its name is not a user list!

It's a usable solution if a few users share one page or if you want to have a template for temporarily restricting access to page content. Just insert the user names into the first parameter of the template, and you're done. And if you want, you can also use a user list name among them. For example, users from the list on the Readers page would not be able to edit the test-page page content in this case, but they could still read the page and track its changes.

However, if you try to use such a test-page page as a user list, you'll run into trouble! AccessControl will attempt to extract the list of authorized users from it — but this will only succeed if at least part of the page content matches the original user list syntax. If it returns just an empty list, AccessControl will deny access and redirect you away.

When you cannot access a page

Don't panic!

If you accidentally removed your name from the list of users authorized to edit the page and you know another user who has permission to edit the page, you can try asking them to correct your mistake and add you back to the list.

If you don't know anyone like that and no other user has access to the page, you'll need to ask for help from a user with administrative rights ('sysop').

However, they won't be able to help you if the privileged status of this user group is restricted through $wgAdminCanReadAll, or if you manage to block access to the page in such a way that even an administrator (user in the 'sysop' group) cannot access it. Such a situation can occur, for example, in the case of multiple transclusions.

Then you have only one option.

If you don't have access to the configuration file LocalSettings.php, you must ask someone who does to temporarily deactivate the AccessControl extension so that you can fix the faulty entry or have them fix it for you. The simplest and fastest solution is to completely delete the content of the page. You can then retrieve it from a previous revision, minimizing the time needed for them to resolve your issue.

Be aware that while the AccessControl extension is inactive, every user can read the content of pages that should be protected by it! Therefore, it is desirable to resolve the issue as quickly as possible and immediately reactivate the AccessControl extension afterwards.

Make previews through page saving

If you make a preview before saving the content of the page that is to be protected via AccessControl, in case you haven't disabled the redirection ($wgAccessControlRedirect) and you are not in the 'sysop' group, you will be redirected immediately, preventing you from saving the changes.

That will protect you from being "cut off" from the page in case you forget to grant yourself access to edit the page's content.

Using MediaWiki for private communication

MediaWiki can replace email conferences.

If a group of users wants to discuss among themselves without public participation, they just need to "lock" a discussion page to themselves. The page can contain public content on the discussion topic, and they can simultaneously debate on the protected discussion page.

All a user needs to do is set up tracking for this discussion page. If its content changes, they'll see a notification in the header.

It's up to them whether they also want to receive notifications about changes via email.

Public and private content on one page

AccessControl always protects the entire page, even across pages into which the protected page is transcluded, but if you have the extension Labeled Section Transclusion installed, there is a way to expose the content of a protected page so that it is publicly accessible.

If you have this manual imported into your instance of MediaWiki, which has the Labeled Section Transclusion extension available, you can try it out on the test page test-page.

1. Set up the page test-page to be protected via AccessControl.
2. Under the template or tag through which it will be protected, add a new section named PUBLIC.
3. In this section, place the content you want to publish without protection.

You will then offer all the content of this section (including subsections) via another, unprotected page, into which you will insert the following code:

{‌{#lsth:test-page|PUBLIC}‌}

Similarly, you can even manage content shared among different user groups within one page. For AccessControl, the permissions that appear last on the page are decisive. Each section can be protected separately, and if the permissions that allow you to edit the page are at the very end, you can manage them all at once.

You can then publish their content in a similar way to a page for anonymous users. Will AccessControl protect pages when using DPL?

The link|accesscontrol-lsth extension is used with templates that automatically generate page content. Compromise of content is possible similarly to the Labeled Section Transclusion extension, but only if sensitive content is placed in a section that can be pulled via its name. When pulling content that will contain code interpreted by AccessControl as a protective element, all generated content will be automatically protected.

Of course, this can be counterproductive if someone places a protected page in a category from which content is generated. Therefore, consistently use <section> tags when writing summaries and annotations to ensure that only what you intend is published from the page.

Version History of the AccessControl Extension

Verze 1.0

První verze rozšíření AccessControl (1.x) vznikla jako vylepšená alternativa k rozšíření Group Based Access Control pro MediaWiki verze 1.12.x

Verze 1.1 až 1.3

Tyto verze fungovaly u MediaWiki ≤ 1.17. Od května 2012 se stal kód rozšíření součástí oficiálního git repozitáře MediaWiki.

• Od pozdějších verzí se lišily tím, že akceptovaly také skupiny MediaWiki, ovšem pouze v kanonické formě. Tj. muselo se použít 'sysop', místo 'Správce'.
• A tag <accesscontrol> se mohl na stránce objevit i vícekrát.
• Také již bylo možné použít proměnnou $wgAdminCanReadAll

Verze 2.0 a 2.2

MediaWiki verze 1.18, sebou přinesla změny, kvůli nimž bylo nutné rozšíření přepsat. Byl odstraněn nevyužívaný kód a protože u tahle verze již neakceptovala standardní skupiny MediaWiki, bylo navýšeno hlavní číslo verze na 2.0.

Pro tuto verzi, byly uvolněny dvě subverze a byla použitelná až do MediaWiki verze 1.20

• Tahle verze již pracovala pouze s uživatelskými seznamy určenými ke zpracování přes Accesscontrol
• Na stránkách zpracovávala pouze první výskyt tagu accesscontrol
• A pokud jméno uživatele bylo na více než jednom seznamu, pak se použil automaticky ten co mu poskytoval vyšší práva (edit)

S těmito verzemi se ale táhnul i nepříjemný problém. Pokud se při vyhledávání na stránkách MediaWiki našel hledaný řetězec i na chráněné stránce, tak se na stránce objevila chyba a neoprávněný (anonymní) uživatel se tak nedostal k výsledkům vůbec. Uspokojivě vyřešila tenhle problém až verze 3.0.

Verze 2.2

Protože se od MediaWiki verze ≥ 1.21 začal používat nový framework ContentHandler, který umožňuje měnit typ wiki stránky podle obsahu, bylo nutné kód rozšíření upravit, aby mohl dál fungovat.

Výsledkem byl AccessControl verze 2.2, uvolněný v říjnu 2013 a tahle úprava kódu prodloužila použitelnost verze 2.x až k současným verzím MediaWiki.

Verze 2.5

V srpnu 2015 byla uvolněna verze 2.5, u které se nově objevila proměnná $wgAccessControlRedirect. Díky ní bylo možné neoprávněného uživatele přesměrovat na informační stránku, na které se dozvěděl, že se pokusil dostat ke chráněnému stránku.

Tahle úprava sebou ale přinesla jiný efekt, již zmíněný výše a to, že se tím významně ušetřila práce webovému serveru, protože mohl indexovacím robotům nabídnout náhradní obsah.

Tato verze byla poslední, kterou se podařilo dostat do oficiálního repozitáře MediaWiki a fungovala, dokud do ní Siebrand Mazeland neposlal změny, které sice měly umožnit registraci tohoto rozšíření přes funkci $wfLoadExtensions(), ale znemožnily jeho fungování pro starší verze MediaWiki < 1.25

Jako maintaner rozšíření AccessControl jsem tomu nemohl zabránit, protože mi v té době již nefungovalo přihlašování do Gerritu. Nemohl jsem tedy změny odmítnout a vynutit si kód, který by umožnil používat oba způsoby registrace, jako to umožňují jiná rozšíření.

Verze 2.5.1

Tahle verze implementovala novou proměnnou $wgAccessToHistory, která měla umožnit anonymním uživatelům přístup k historii a wikikódu nechráněných stránek. Byla uvolněna na konci února 2016, ale díky nekompatibilnímu kódu, který prošel do oficiálního repozitáře rozšíření, se do něj nikdy nedostala.

Verze 2.6

Jádro kódu je u verze 2.6 stejné jako verze 2.5, ale kvůli registraci přes $wfLoadExtensions() vyžaduje MediaWiki ≥ 2.5

Verze z Hackatonu 2019

Ve dnech 17.–20. května 2019 se konal v Praze (Česká republika) Wikimedia Hackaton 2019. Těsně před touto akcí mne kontaktoval Nicolas Nallet, jestli bychom se při této příležitosti nesetkali, abychom mohli společně rozšíření AccessControl vylepšit.

Sešli jsme se a Nicolas přišel s nápadem, jak by se dalo efektivně při práci s uživatelským seznamem využívat rozšíření Page Forms. Výsledkem byl rozšířený kód, na kterém mohl Nicolas provést první testy již během Hackatonu. Nicméně tou dobou jsem byl již rozhodnut, kód rozšíření radikálně předělat.

Verze 3.0

The beta version of the extension was completed about a week ago. Exactly one month after the end of Hackathon 2019, the pre-release version was released and made available for testing.

The release of the final version was associated with the completion of this user documentation because the code had been completely rewritten and brings a number of new features.

Recommended and Proven Extensions

AccessControl is an extension that has no dependencies. However, I strongly recommend that your wiki includes the following set of extensions, which will allow you to program sophisticated templates using wiki code within the MediaWiki environment.

There's no reason to install Scribunto and program in Lua for simple templates!

DynamicPageList3

A sophisticated extension that allows generating dynamic page content using templates.

Labeled Section Transclusion

It allows extracting selected sections from the content of pages.

Loops

It allows using loops in templates.

MyVariable

It adds several useful magic words that can be further utilized in templates.

Page Forms

It allows managing lists of users that AccessControl works with through forms.

ParserFunctions

It offers a wide range of features that enable sophisticated template programming.

SubPageList

It allows listing subpages as a list, which can be further processed using functions provided by the ParserFunctions extension, loops, etc.

Translate

An extension for translating content for multilingual wikis

Variables

It allows defining and using variables in templates.

Mentioned Extensions

DisableSpecialPages

An unmaintained extension that allowed disabling special pages. Here is an alternative solution using a custom function.

Scribunto

An extension that allows programming modules in the Lua language

Anchors Used on the Page

Anchor	Description
accesscontrol-accesslist	Lists of authorized users and their usage
accesscontrol-deny	What to do when you've blocked access to a page
accesscontrol-dpl	Security risks when using the DynamicPageList3 extension
accesscontrol-export	Section dedicated to restrictions on exporting data from MediaWiki
accesscontrol-history	Link to the historical overview of the development of the AccessControl extension
accesscontrol-info	Section dedicated to the page MediaWiki:Deny user
accesscontrol-install	Anchor to the chapter on installing the extension
accesscontrol-lsth	Security risks when using the Labeled Section Transclusion extension
accesscontrol-old-syntax	Chapter dedicated to the original syntax of user lists
accesscontrol-tag	The original page protection system, utilizing the <a‌ccesscontrol> tag
accesscontrol-test	Testing protection on the test page test-page
accesscontrol-template-options	Page protection with a parameterized template
accesscontrol-template-name	Page protection with a template named with the string "accesscontrol" in the title (alternative to the <a‌ccesscontrol> tag)
config-basic	Default wiki configuration before installing the AccessControl extension
config-extension-rights	Preventive restriction of rights associated with extensions
config-extra	Restricting access to special pages
how-accesscontrol-detect	Link to the section where it describes how protected content is detected
how-accesscontrol-work	Link to the section where the method of checking page content is discussed
mediawiki-groups	MediaWiki user groups
mediawiki-preview	Recommended procedure for saving changes after editing a page with protected content
namespace-private	When it makes sense to create custom namespaces and how to set access control for them only to selected user groups in the LocalSettings.php file.
mediawiki-private-channel	How to use page protection via AccessControl for private communication.
not-accesslist	Warning that the behavior of a named template is different from a template using options
only-example-code	Warning against mindless code copying
option-template	Warning against using a template instead of a username or user list
page-lock	Locking pages. When and where to use it.
public-and-private	Procedure for mixing private and public content on one page.
template-atack	How to exploit a wiki using the parameter of the AccessControl extension.
template-is-better	Why it's better to use a template rather than the <a‌ccesscontrol> tag
template-tag-difference	The difference in processing strings passed through template parameters and processing the content of the first attribute in a template with the string a‌ccesscontrol in its name (the same applies to processing the content of the <a‌ccesscontrol> tag)