MediaWiki is designed for the most part to be an open document repository. In most setups (presumably), everyone can read and only registered users can edit. However, permissions can't get much more granular than this. For my project at least, I would like to not just limit anonymous users from editing, I would like to selectively limit them from reading certain things.
I looked around for quite some time until I came upon a variable you can set in
your LocalSettings.php file: $wgWhitelistRead
. Basically, this variable
whitelists the pages specified in the array. The downside to this is you can't
use wildcards or namespaces/categories. You must specify a single page per
array value. This doesn't quite cut it for my needs. That being said, here's my
solution (albeit rough).
The end goal here looks like this...
To do this, in your LocalSettings.php file, place the following four lines...
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['read'] = false;
$wgGroupPermissions['user']['edit'] = false;
Once you have the lines in the last section in your config file, your entire wiki should be unavailable, even to sysop people (they are users after all). To give access back to your sysop folk, place the following two lines in your LocalSettings.php file
$wgGroupPermissions['sysop']['read'] = true;
$wgGroupPermissions['sysop']['edit'] = true;
This will only grant access to your sysop authenticated users. If they're not already authenticated, they still can't get to the Special:UserLogin form (we'll get to that in just a few) to login. They may be sysops at heart, but hearts don't authenticate people without usernames and passwords.
Now that our sysops have permissions, next we need a custom group so we can grant permissions to them. We'll call that group 'GreenTea' (yes, I'm drinking some green tea right now). To do that, let's throw another few lines in the LocalSettings.php file...
$wgGroupPermissions['greentea'] = $wgGroupPermissions['user'];
$wgGroupPermissions['greentea']['read'] = true;
$wgGroupPermissions['greentea']['edit'] = true;
Now that our group is set up, we need to whitelist the necessary and wanted pages for anonymous folk to log in and/or do their thing depending on what groups they are in. To do this, let's add yet another few lines to our LocalSettings.php file
$wgWhitelistRead = array(
'Main Page',
'Special:Userlogin',
'Special:UserLogout',
);
What we just did was whitelist the main page, the login page, and the logout page. This allows users to get in and out of your wiki, whether or not their permissions allow them access to anything. At this point, you can log in with your sysop user and put people into our previously created 'greentea' group. Once that's done, the greentea users should have full access to the entire wiki.
I would like to note here that that this point, users outside of the greentea group will have the same permissions as anonymous/unauthenticated users. They cannot read or edit any pages other than the ones currently whitelisted.
This is the only part that's out of the ordinary here. We are going to edit actual MediaWiki code. The big downside to doing this is that if the MediaWiki instance is upgrade, it is highly likely that the changes made in this section will be overwritten. Thankfully though, the changes are very simple, so making them again shouldn't be a problem. They're so simple in fact, I think the MediaWiki folks might actually accept my code into their branch.
To set up our MediaWiki instance so it handles regex whitelist statements, we need to edit the Title.php file in the includes directory.
Firstly, we need to comment out the code that processes the whitelist variable. Head to around line 1870 in Title.php and comment out just the following lines
//Check with and without underscores
if ( in_array( $name, $wgWhitelistRead, true ) || in_array( $dbName, $wgWhitelistRead, true ) )
return true;
Now that those have been commented out, we need to add in the code that will process regex statements in the whitelist array. Below the lines you just commented out, add the following code...
foreach ( $wgWhitelistRead as $item )
if ( preg_match( '/^'.$item.'$/', $name )
|| preg_match( '/^'.$dbName.'$/', $name ) ) return true;
To use the changes we just put in place, all that needs to be done is edit the $wgWhitelistRead variable in LocalSettings.php again.
Say, for example, that we have a 'HowTo' namespace ('HowTo:Drink Green Tea' for example) that we want everyone to be able to read that isn't in the greentea group (they have to learn somehow after all). All that needs to be done is a little regex...
$wgWhitelistRead = array(
'Main Page',
'Special:Userlogin',
'Special:UserLogout',
'HowTo:.*',
);
That just whitelisted all pages inside the 'HowTo' namespace.
In case anyone who doesn't know is wondering why you put a .* at the end of the HowTo namespace, here you go.
In regular expressions, various symbols have different meanings. In this case,
the period signifies any case letter, number, symbol, etc. That means that
HowTo:.
would match anything like HowTo:A
, HowTo:3
, HowTo:-
, etc. It
would however not match HowTo:A123
. Why? The period in regular expressions
matches only one character. What we need is to say match any character any
number of times after 'HowTo:'. For that we'll need the asterisk.
The asterisk in regular expressions is what we call a quantifier. It doesn't
represent a character so much as a quantity. In non regex terms, an asterisk
means that the previous character in the regex string can be repeated zero or
more times and still match. That means that the regular expression c*
would
match nothing, c
, cccc
, cccccc
, etc. It would however not match for
example, b
, 5
, 12345a
, etc. In our example, HowTo:.*
, the period
represents any character and it is followed by an asterisk, so that means that
any article that starts with 'HowTo:' will match, no matter what the ending,
even if it doesn't have one.
Hopefully someone finds this post useful. If anyone has questions about .* please ask them in the comments.
Written on: 2015-06-01 21:53:17 -0600
Last edited: 2025-03-06 23:41:07 UTC