|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
||This extension requires patches to core MediaWiki code. Extensions implemented using patches may be disabled by or interfere with upgrades and security patches. If a suitable alternative without a patch is available, we recommend you use that extension instead.|
Release status: beta
|Description||Can make custom namespaces accessible only to users with permission|
Currently maintained by Kristian Spilhaug (KristianStalk)
|Latest version||1.16.1 (2011-02-17)|
|MediaWiki||1.4 to 1.8.2 found at Bugzilla.
1.8.2+ found at SourceForge
|License||GNU General Public License|
Translate the Hidden pages extension if it is available at translatewiki.net
|Check usage and version matrix; code metrics|
On Mediawiki, under some circumstances, you'd like to have some information not publicly available and only for the management - for instance private addresses, press contacts, financial issues and preparation of surprises.
Normally this information is separated from the Wiki inside of mailing lists, forums or a separate Wiki, but this is very uncomfortable. MediaWiki is designed as an open Wiki Engine without complicated management of users, groups and rights and it should stay as open and simple as possible.
This extension modifies core MediaWiki code in order to restrict access to custom namespaces. The patch comes with no warranty, and it is likely that there are ways of circumventing the privacy it offers. Please do not use it to protect critical information.
Hidden namespaces patch
The patches introduce a feature that allows restricting access to namespaces. Without the right privileges, users can neither read nor write articles in the secured namespaces. Articles in secure namespaces do not appear in Recent Changes nor in search, unless the performing user has the necessary rights.
Installing the patch
Install the patch using the linux command line command patch. Like so:
patch -p1 < hidden-1.XX.X.patch
Place the patchfile in the root of the mediawiki directory, and run the command from there. (See wikipedia:Patch (Unix) for additional information.)
Installing modified files
The patch is also available as pre-patched files adaptable to several versions of MediaWiki, from 1.10.1 and up. (Some versions are not represented).
Replacing the original files with the pre-patched files will install the patch. See the README-file included in the package for details.
Configuring the installed patch
Initial setup is done by adding code to your LocalSettings.php-file.
First: Use the variable $wgExtraNamespaces to create custom namespaces. See Custom Namespaces for more information.
NOTE: Custom made namespaces may conflict with namespaces established by other extensions. Check Extension namespace registration to avoid this.
Example: To create the custom namespaces "Backstage" and "Secret" (noting that discussion pages must be created as well) add the following code:
$wgExtraNamespaces = array ( 1000 => "Backstage", 1001 => "Backstage_talk", 1002 => "Secret", 1003 => "Secret_talk");
Second: Use the new variable $wgRestrictedNamespaces to define your restricted namespaces, and define user groups with access to them.
NOTE: The desired groupname cannot contain a space or _. It must consist of letters and numbers only.
Example: To limit access to the custom namespaces "Backstage" and "Secret" (and their appropriate discussion pages), add the following code:
$wgRestrictedNamespaces = array ( 1000 => "backstageGroup1", 1001 => "backstageGroup2", 1002 => "secretGroup1", 1003 => "secretGroup2");
Third: Use the variable $wgGroupPermissions to define custom named user rights for the appropriate user groups. See User rights management for more information.
Example: To grant users with "backdoor"-privileges access to the limited namespace "Backstage", and to grant users with "secrecy"-privileges access to the limited namespace "Secret" (and their appropriate discussion pages), add the following code:
$wgGroupPermissions['backdoor']['backstageGroup1'] = true; $wgGroupPermissions['backdoor']['backstageGroup2'] = true; $wgGroupPermissions['secrecy']['secretGroup1'] = true; $wgGroupPermissions['secrecy']['secretGroup2'] = true;
Fourth: Use the variable $wgNonincludableNamespaces to deny inclusion of pages from restricted namespaces. See Help:Transclusion for more information.
Example: To deny inclusion of pages from the custom namespaces "Backstage" and "Secret" (and their discussion pages), add the following code:
$wgNonincludableNamespaces = array ( 1000, 1001, 1002, 1003);
Fifth: The patch makes use of three custom system messages, which should be created.
- The patch creates a sidebar with a list of available restricted namespaces.
MediaWiki:RNSlist provides a title for the sidebar list.
- If users without proper permission attempts to access a restricted page they will see a default "access denied"-message.
MediaWiki:noaccesstitle and MediaWiki:noaccesstext will provide a custom title and text for the "access denied" page for restricted namespaces.
Granting user rights
Once the patch is installed and configured, user rights can be granted through the Special:Userrights page, by any user with permissions to grant and revoke user rights.
- Articles from restricted namespaces can't be used as templates, because of the page caching.
- The patch is not tested on default namespaces (id < 100)
- The patch does not support hidden images
- It does, however, hide links to restricted pages that use images.
- Add usage description
Thoughts around limiting access
Here are some thoughts on introducing the feature of hidden pages that are only visible and editable by some users. Wikipedia does not want such pages but other projects may.
Making it simple
- If hidden pages are defined for whole namespaces you do not add a function to hide/unhide pages. You could use the 'Projectname'-Namespace or additional namespaces like 'intern'
- If only admins can read and edit hidden pages you do not have to add more user rights management than we[who?] already have.
Making it secure
Which parts of the software contain functions that return page content?
- Export XML (less important, can be switched off)
- Recent changes as RSS? (less important, can be switched off)
- Parser (for templates)
- SearchEngine (searches return content snippets)
Which parts of the software contain functions that return article titles?
- Recent changes
- Recent changes in RSS? (less important, can be switched off)
Where is the best point to add the code that prohibits access to hidden pages for non-admins?
1. Maybe you can add something like
AND NOT cur_namespace = H1 AND NOT NOT cur_namespace = H2 ...
in the SQL statement there with H1...H2 as hidden namespaces?
2. Or set title= if user is not an admin and title='intern:...'
- Extension:NamespacePermissions which uses separate permissions for each action (read,edit,create,move) on each custom namespace for granting access to the articles in those namespaces. (Please Note: this extension has been archived for security reasons.)
- It is an extension, not a patch, and therefore it is easier to install. It is also more powerful because it provides more grained access than the patch described above.
- Extension:Page access restriction, with Page-By-Page Restriction
- Extension:PageSecurity implements many of the requisites described on this article.