README

   1 --------------------------------------------------------------------------
   2 README for the Lockdown extension
   3 Copyright © 2006 Daniel Kinzler
   4 Licenses: GNU General Public Licence (GPL)
   5           GNU Free Documentation License (GFDL)
   6 --------------------------------------------------------------------------
   7
   8 The Lockdown extension implements a way to retrict access to specific
   9 namespaces and special pages to a given set of user groups. This provides
  10 a more fine grained security model than the one provided by the default
  11 $wgGroupPermissions and $wgNamespaceRestrictions settings.
  12
  13 <https://mediawiki.org/wiki/Extension:Lockdown>
  14
  15 The Lockdown extension was originally written by Daniel Kinzler in 2007
  16 and is released under the GNU General Public Licence (GPL).
  17
  18 The following pages about the security model used by MediaWiki per
  19 default may be helpful to understand the instructions below:
  20
  21 * <https://www.mediawiki.org/wiki/Help:Managing_user_rights>
  22 * <https://www.mediawiki.org/wiki/Manual:$wgGroupPermissions>
  23
  24
  25 == WARNING: restricting read access not fully possible ==
  26
  27 Mediawiki is not designed to be a CMS, or to protect sensitive data.
  28 To the contrary, it was designed to be as open as possible. Thus it does
  29 not support full featured, air-tight protection of private content.
  30
  31 This extension can be used to apply read-restrictions to namespaces,
  32 limiting read access to specific groups. Note however that there may be
  33 several ways in which data thusly protected may be "leaked" to the public:
  34
  35 * it is possible to include protected pages as templates, making them
  36   readable. This is addressed by the $wgNonincludableNamespaces setting
  37   introduced in MW 1.10, revision 19934.
  38
  39 * it is possible to export pages without having read-access to them using
  40   Special:Export. This has been fixed in MW 1.10, revision 19935.
  41
  42 * Content of newly created pages, and changes to existing pages, are shown
  43   in the RSS/Atom feeds provided by Special:recentchanges, without checking
  44   read permission. This has been fixed in MW 1.10, revision 19944.
  45
  46 * Read-Permission only applies to page content. "Hidden" pages are still
  47   listed in categories, Special:Allpages, etc. Also, changes to "hidden"
  48   pages are still shown Special:Recentchanges, etc, including the edit
  49   summary.
  50
  51 * Excerpts of page content may be shown by Special:Search, regardless of
  52   read permission.
  53
  54 There are probably more "holes" in the read protection system. So,
  55 denying read access should be seens as a "nothing to see here, move
  56 along", rather than a guarantee of secrecy.
  57
  58
  59 == Installing ==
  60
  61 Copy the Lockdown directory into the extensions folder of your
  62 MediaWiki installation. Then add the following lines to your
  63 LocalSettings.php file (near the end):
  64
  65   wfLoadExtension( 'Lockdown' );
  66
  67   $wgSpecialPageLockdown['Export'] = ['user'];
  68
  69   $wgNamespacePermissionLockdown[NS_PROJECT]['edit'] = ['user'];
  70
  71 The settings for $wgSpecialPageLockdown and $wgNamespacePermissionLockdown
  72 are just examples - see below for details.
  73
  74
  75 == Configuration ==
  76
  77 Note that the Lockdown extension can only be used to *restrict* access,
  78 not to *grant* it. If access is denied by some build-in setting of
  79 MediaWiki, it cannot be allowed using the Lockdown extension.
  80
  81
  82 === $wgSpecialPageLockdown ===
  83
  84 $wgSpecialPageLockdown allows you to specify for each special page which
  85 user groups have access to it. For example, to limit the use of
  86 Special:Export to logged in users, use this in LocalSettings.php:
  87
  88     $wgSpecialPageLockdown['Export'] = ['user'];
  89
  90 Note that some special pages "natively" require a specific permission.
  91 For example, Special:Userrights, which can be used to assign user groups,
  92 required the "userrights" permission (granted only to the "bureaucrat"
  93 group per default). This restriction can not be overridden using the
  94 Lockdown extension.
  95
  96 === $wgActionLockdown ===
  97
  98 $wgActionLockdown allows you to specify for each actionwhich user groups
  99 have access to it. For example, to limit the use of the history page to
 100 logged in users, use this in LocalSettings.php:
 101
 102     $wgActionLockdown['history'] = ['user'];
 103
 104 Note that some actions can not be locked down this way. In particular, it
 105 will not work for the ajax action.
 106
 107
 108 === $wgNamespacePermissionLockdown ===
 109
 110 $wgNamespacePermissionLockdown lets you restrict which user groups have
 111 which permissions on which namespace. For example, to grant only members
 112 of the sysop group write access to the project namespace, use this:
 113
 114     $wgNamespacePermissionLockdown[NS_PROJECT]['edit'] = ['sysop'];
 115
 116 Wildcards for either the namespace or the permission (but not both at once)
 117 are supported. More specific definitions take precedence:
 118
 119     $wgNamespacePermissionLockdown[NS_PROJECT]['*'] = ['sysop'];
 120     $wgNamespacePermissionLockdown[NS_PROJECT]['read'] = ['*'];
 121
 122     $wgNamespacePermissionLockdown['*']['move'] = ['autoconfirmed'];
 123
 124 The first two lines restrict all permissions in the project namespace to
 125 members of the sysop group, but still allow reading to anyone. The third
 126 line limits page moves in all namespaces to members of the autoconfirmed
 127 group.
 128
 129 Note that this way, you cannot *grant* permissions that have not been
 130 allowed by the build-in $wgGroupPermissions setting. The following does
 131 *not* allow regular users to patrol edits in the main namespace:
 132
 133     $wgNamespacePermissionLockdown[NS_MAIN]['patrol'] = ['user'];
 134
 135 Instead, you would have to grant this right in $wgGroupPermissions first,
 136 and then restrict it again using $wgNamespacePermissionLockdown:
 137
 138     $wgGroupPermissions['user']['patrol'] = true;
 139
 140     $wgNamespacePermissionLockdown['*']['patrol'] = ['sysop'];
 141     $wgNamespacePermissionLockdown[NS_MAIN]['patrol'] = ['user'];
 142
 143 Note that when restricting read-access to a namespace, the restriction can
 144 easily be circumvented if the user has write access to any other namespace:
 145 by including a read-protected page as a template, it can be made visible.
 146 To avoid this, you would have to forbid the use of pages from that namespace
 147 as templates, by adding the namespace's ID to $wgNonincludableNamespaces
 148 (this feature was introduced in MediaWiki 1.10, revision 19934):
 149
 150     $wgNamespacePermissionLockdown[NS_PROJECT]['read'] = ['user'];
 151     $wgNonincludableNamespaces[] = NS_PROJECT;
 152
 153 PLEASE READ THE SECTION "WARNING: restricting read access not fully possible"
 154 FOR MORE INFORMATION ABOUT THE LIMITATIONS OF RESTRICTING READ ACCESS!
 155