MediaWiki修改：隐藏页面

页面分类: 待翻译文章 | MediaWiki tools | MediaWiki Development | Mediawiki Hacks | MediaWiki技术文档

天下维客，你可以修改的网络知识库

本文取自元维基，欢迎共同翻译、整理与大家共享，促进中文wiki发展^_^

Wikis are great and MediaWiki is a great Wiki engine (Warning: POV ;-) ) But under some circumstances you'd like to have some information not publicly available but only for the management - for instance private addresses, press contact, financial issues and preparation of surprises. Normally this information is separated from the Wiki inside of mailings lists, forums or a separate Wiki. 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.

Possible approaches

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)

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

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

Possible solution (Namespace-Based Restriction)

Installing the patch

Experimental patches for 1.4.(1,3,5) and HEAD/1.5 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.

Configuration

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 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.

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]

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...

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?

A different approach (Page-By-Page Restriction)

A second, independent approach can be found at Page access restriction with MediaWiki

原文参见： Hidden pages