Extension:Hidden pages

From MediaWiki.org

Manual on MediaWiki Extensions
List of MediaWiki Extensions

Hidden pages Release status: unknown
Implementation	User rights
Description	Create new namespaces that can be accesible only by some users
Download	no link

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.

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.

[edit] Possible approaches

[edit] 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

[edit] 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.

[edit] 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:...'

[edit] Possible solution (Namespace-Based Restriction)

Note: Updates for the following patch has moved from Bugzilla to the SourceForge project hiddenwiki.

[edit] Installing the patch

Experimental patches for MW from 1.4 to 1.8.2 can be found at Bug 1924: Restricted read access for subset of wiki. Install them using the linux command line command patch. Like so:

patch -p1 < patchfile.patch

cd to the root of the mediawiki directory to run this command. (See wikipedia:Patch (Unix) for additional information.)

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. Such articles don't appear in Recent Changes nor in the search, unless the performing user has the necessary rights.

[edit] Configuration

[edit] version 1.4

Create a new custom name space using the existing functionality for Custom Namespaces

Then, use the new variable $wgRestrictedNamespaces to limit access. The variable takes an array of user rights. For example, to create a sysop-only namespace, use:

$wgExtraNamespaces = array(100 => "Sysopspace", 101 => "Sysopspace_Talk");
$wgRestrictedNamespaces = array(100 => array ("sysop"), 101 => array ("sysop"));

As user rights are just strings, it is possible to set up user groups like "win_users". However, you need to modify the user rights directly in the database to do so. This is done in the table user_rights, in the field ur_rights. Check m:Setting user rights in MediaWiki for a description how this is done.

Note that multiple user rights may be specified in the array above. For example:

$wgRestrictedNamespaces = array(100 => array ("sysop","win_users"), 101 => array ("sysop","win_users"));

Results in namespaces that require both the "sysop" and "win_users" rights in order to access. There does not appear to be a way to require only one of a set of user rights for access (e.g. either sysop or win_users, in the example above).

Alternatively, a user with Developer and Bureaucrat rights can use Special:Makesysop to set the rights through the web.

[edit] version 1.5

You'll need to define accesskeys / groups of namespaces, which then can be used in $wgGroupPermissions. The following example should do the same as the code given above:

$wgExtraNamespaces = array(100 => "Sysopspace", 101 => "Sysopspace_Talk");
$wgRestrictedNamespaces = array(100 => "namespaceGrp1", 101 => "namespaceGrp2");
 
$wgGroupPermissions['sysop']['namespaceGrp1']      = true;
$wgGroupPermissions['win_users']['namespaceGrp1']  = true;
$wgGroupPermissions['sysop']['namespaceGrp2']      = true;
$wgGroupPermissions['win_users']['namespaceGrp2']  = true;

NOTE: The desired groupname can not contain a space or _. It must consist of only letters and numbers. It took me a while to figure this out so I hope this prevents headaches for others.

More info can be found in DefaultSettings.php after patching.[1]

[edit] Restrictions

• Articles from restricted namespaces can't be used as templates, because of the page caching.
• I did not test what happens if a default namespace (id < 100) is restricted...

[edit] To Do

• Moving and protecting a page creates an entry in RecentChanges that is not linked to the namespace. These changes are visible to everyone.
• Through Special:Allpages, it is possible to detect the names of all namespaces, even the hidden ones.
• Enotif sends messages whenever a page is created; this has to be restricted to the visible namespaces.

This is fixed in recent 1.5 patches?

• Does it support hidden images?
  • How do we create custom image namespaces?

[edit] Another solution for Namespace-Based Restriction

One can use 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.

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.

[edit] A different approach (Page-By-Page Restriction)

A second, independent approach can be found at Extension:Page access restriction

[edit] Yet another approach

The PageSecurity extension implements many of the requisites described on this article.