Extension:Hidden pages

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 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", (note that discussion pages must be created as well), add the following code:

Second: Use the new variable $wgRestrictedNamespaces to define your restricted namespaces, and define user groups with access to them. NOTE: The desired groupname can not contain a space or _. It must consist of only letters and numbers. Example: To limit access to the custom namespaces "Backstage" and "Secret" (and their appropriate discussion pages), add the following code:

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:

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:

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.

Restrictions

 * 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 uses images.

Todo

 * 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. We do not want such pages in Wikipedia but other projects may need them.

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 already have

Making it secure
Which parts of the software contain functions that return page content?


 * OpenPage
 * Editpage
 * Diff
 * Export XML (less important, can be switched off)
 * Recent changes as RSS? (less important, can be switched off)
 * Randompage
 * Parser (for templates)
 * SearchEngine (searches return content snippets)
 * Special:Log

Which parts of the software contain functions that return article titles?
 * Recent changes
 * Watchlist
 * Recent changes in RSS? (less important, can be switched off)
 * Whatlinkshere
 * Lonelypages
 * Uncategorizedpages
 * Popularpages
 * Shortpages
 * CategoryPage
 * QueryPage
 * SearchEngine
 * SpecialAllpages
 * SpecialContributions
 * SpecialLog
 * SpecialRecentchangeslinked
 * SpecialWantedpages

Other parts
 * Rename

See also Security issues with authorization extensions.

Implementation
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:...'