There are few pages on our wiki that I'd like to be able to protect from editing by people other than the assigned owner of that page.
We're currently running MediaWiki v1.15.4 and are unable to update to 1.18 for the time being.
Thanks in advance.
Edit: Just to clarify, the permissions need to be set for individual users and not by groups.
I had a similar problem where I needed more flexibility than the default system offered. I solved this by this script (embedded in a mediawiki extension):
// check each page for gossip permissions
$wgHooks['ArticlePageDataBefore'][] = 'GossipProtection_check_permissions';
/**
* ArticlePageDataBefore hook
*
* $article: article that is requested
* ($fields: not important)
*/
function GossipProtection_check_permissions($article, $fields) {
global $wgUser;
$title = $article->getTitle()->mTextform;
if(is_gossip_page($title))
if(!this_user_is_allowed_on_page($title))
die('You are not allowed on this page');
return true;
}
But using mediawiki's protection service is off course more elegant. You could for example create a group for the allowed users.
Related
I'm trying to setup a MediaWiki for university students. Using the EmailDomainCheck, I prevent anyone except those with a university based email from creating accounts. Using $wgEmailConfirmToEdit, I can require that an email is confirmed before the user can edit files. However, as it is, a user can use a fake email from the correct domain to create an account. With the account they can view all pages (even though they cannot edit them). I do not want to grant them read access unless the email has been confirmed. Is this possible? Note, I want all confirmed emails of the correct domain to be automatically accepted. It should not require manual account creation acceptance.
You could try the following, as outlined in the Documentation
# Disable for everyone.
$wgGroupPermissions['*']['read'] = false;
# Disable for users, too: by default 'user' is allowed to read, even if '*' is not.
$wgGroupPermissions['user']['read'] = false;
# Make it so users with confirmed email addresses are in the group.
$wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;
# Hide group from user list.
$wgImplicitGroups[] = 'emailconfirmed';
# Finally, set it to true for the desired group.
$wgGroupPermissions['emailconfirmed']['read'] = true;
As Jenny Shoars has mentioned, you may wish to whitelist some pages such as:
$wgWhitelistRead = array("Main_Page", "Special:CreateAccount", "Special:ConfirmEmail");
So that non registered users can still create accounts and the like.
In theory,
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['emailconfirmed']['read'] = true;
should work. In practice, MediaWiki almost always used with an "everyone can read" or "you can read iff you are logged in" setup and others are not very well tested, so if that wiki had some highly sensitive private information I wouldn't do this, but I imagine for a university website that's not the case.
Alternatively, it should not be too hard to integrate an email confirmation step into account creation, but you'd have to write the code for that. EmailAuth (which does a similar check during login) might give you an idea of how that would look.
Several years ago, I used mediawiki to create a wiki. I had(still have) no idea really how to administrate it. I wanted it to be maintained/updated by only myself. It was to hold a specific set of information for my users.
After a few weeks it became flooded with User submitted pages (in this case not a good thing) and I guess what you'd call "spammers"(?).
How can I set it up so that only a legitimate admin (me) can add/update page?
I thought I had enabled something to do that...but it apparently didn't work.
In MediaWiki, permissions (read, edit, createpage, etc.) can be granted or refused by configuring the $wgGroupPermissions array in your LocalSettings.php file.
There is a set default groups that you can use with $wgGroupPermissions to restrict page creation/editing:
* - all users (including anonymous)
user - registered accounts
autoconfirmed - registered accounts at least as old as $wgAutoConfirmAge and having at least as many edits as $wgAutoConfirmCount
bot - accounts with the bot right (intended for automated scripts)
sysop - users who by default can delete and restore pages, block and unblock users, et cetera
bureaucrat - users who by default can change other users' rights
The group that would apply to only you (as the creator of the wiki) is the sysop group.
For example, to refuse createpage/edit rights for all users except those with the sysop group, you would place this in your LocalSettings.php:
# Deny createpage and edit rights to all users
$wgGroupPermissions['*']['createpage'] = false;
$wgGroupPermissions['*']['edit'] = false;
# Allow only users with the sysop group createpage and edit rights
$wgGroupPermissions['sysop']['createpage'] = true;
$wgGroupPermissions['sysop']['edit'] = true;
The "*" character indicates that this rule will apply to all groups. Then, we add an exception to that rule for the "sysop" group, allowing users with that group to create or edit pages.
I'm using mediawiki 1.13.3 running on freebsd 7.4
I've got confused with the following task:
how to deny access to All pages for certain users (who has account in my wiki) or for group of these users but allow ReadOnly access for certain pages on wiki.
The goal to achieve is to have no access to pages on wiki except allowed few for some users.
I've tried some extensions but can't find a solution for ~20000 pages and few hundreds of users.
See Manual:Preventing access on mediawiki.org, section "Restrict viewing of all pages".
Specifically, to allow everyone to read (but not edit) the Main Page and a page named Public stuff, and to allow only sysops to read and edit all pages, you'd add the following lines to your LocalSettings.php:
# prevent editing and reading by anons (except for exception listed below):
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;
# same for normal registered users:
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['user']['read'] = false;
# allow everyone read access to these pages:
$wgWhitelistRead = array( "Main Page", "Public stuff" );
# allow sysops to read and edit normally:
$wgGroupPermissions['sysop']['edit'] = true;
$wgGroupPermissions['sysop']['read'] = true;
Of course, you can replace sysop above with your own custom user group; I just used it in the example because it exists in a stock MediaWiki install.
(Some older example code suggests also including "Special:UserLogin" and possibly "Special:ChangePassword" and "Special:PasswordReset" in $wgWhitelistRead. In modern MediaWiki versions this should be unnecessary, although still harmless.)
A quite close solution I've found is using simple security extension:
So I'm creating a user group with no access:
$wgGroupPermissions['user']['read'] = false;
add this group to $wgRestrictionLevels = array();
and then restricting read access for some pages to this group.
Fairly enough but not exactly the solution I want to achieve.
I've installed the AccessControl MediaWiki extension however it seems like it causes an access denied error if you search for anything even contained within the page that is access controlled.
Anyone using this extension?
All I want to do is hide one page in the wiki from everyone except for 5 people.
MediaWiki version 1.18.0
AccessControl version 2.1
I solved it by adding another namespace to put the pages I need to secure in. I then removed the namespace from being searchable by implementing the searchablenamespaces hook.
By doing this, there will never be an access denied page displayed just by searching for text that happens to be in an access controlled page.
Here is the code for $IP/extensions/NoSearchNameSpace/NoSearchNameSpace.php
<?php
// This is a quick hack to remove certain listed namespaces from being searchable
// Just set a list of namespace IDs in the wgNoSearchNamespaces array in LocalSettings
// ie $wgNoSearchNamespaces = array(500,501) would remove 500 and 501 from being searched
$wgHooks['SearchableNamespaces'][] = 'noSearchNameSpace';
function noSearchNameSpace($arr){
global $wgNoSearchNamespaces;
foreach($wgNoSearchNamespaces as $ns){
unset($arr[$ns]);
}
return $arr;
}
Example LocalSettings.php entry:
// Add two custom namespaces. One for ACL pages.
// one for pages that will be ACL'd that should not be searched.
$wgExtraNamespaces[500] = "ACL";
$wgExtraNamespaces[501] = "NoSearch";
// Include the NoSearchNamespace extension
require_once("extensions/NoSearchNamespace/NoSearchNameSpace.php");
$wgNoSearchNamespaces = array('500','501');
I tried it with 1.20.2, and had the problem when a page I was searching for contained text being searched, putting it in the list of search results, which provoked an error because the "hookUserCan" function in AccessControl.php didn't return a value. To try to fix this, I modified line 341 of AccessControl.php ("return doRedirect( 'accesscontrol-info-anonymous' );" to "return false;". This forces the search results to return just the title of the page, and then gets a permission error if an unauthorized user tries to open it. This is not a perfect fix, but it is sufficient for my purposes.
Editted, this is a better answer:
I made some modifications to the AccessControl.php program, and now it appears to work ok with MediaWiki user groups. A remaining problem is that the TITLES of protected pages show in the search results. This is fixable in the main MediaWiki source code (SpecialSearch.php, around line 562), but according to comments in that code, it would screw up the paging.
Here is my git directory, which can be unzipped to $IP/extensions/AccessControl:
https://ejc.s3.amazonaws.com/AccessControlGit.zip
Here is just the AccessControl.php file: http://pastebin.com/WnyB6gBw
Note that this has only been tested (briefly) with MediaWiki 1.20.2. I'm hoping that the author of the extension will review what I did and fix whatever problems remain.
I fixed this error by adding
return false;
after ALL LINES that say
doRedirect( 'accesscontrol-info-anonymous' );
The page view counter on each MediaWiki page seems like a great way to identify popular pages which are worth putting more effort into keeping up-to-date and useful, but I've hit a problem.
We use a Google Search Appliance to index our MediaWiki installation. The problem I have is that the GSA increments the page view counter each time it crawls the page. This completely dominates the statistics, swamping the views made by real users.
I know how to reset the page counters to start again. But is there a way to configure MediaWiki to ignore page requests from the GSA for the purposes of counting page views?
this can be done by adding a condition in Article.php:
includes/Article.php:2861:function viewUpdates():
if( !$wgDisableCounters && !$wgUser->isAllowed('bot') && $this->getID() ) {
add:
&& strpos($_SERVER['HTTP_USER_AGENT'], 'gsa-crawler') === false
where gsa-crawler is part of the default gsa UA...
another way is to setup Forms Authentication in GSA, and have it login to wikimedia as a user in the bot group..
We added this snippet to LocalSettings.php, with great success:
if (strpos($_SERVER['HTTP_USER_AGENT'], 'gsa-crawler') !== FALSE) {
$wgDisableCounters = TRUE;
}
Thanks!