Preventing access

otherlanguages: 中文

Configuration changes can be inserted into LocalSettings.php and must generally appear below the line:

require_once( "includes/DefaultSettings.php" );

Prevent new user registrations

• In order to prevent new user registrations, the following line could be added to the LocalSettings.php file:

Pre-1.5

#   Prevent new user registrations
$wgWhitelistAccount = array ( "user" => 0, "sysop" => 1, "developer" => 1 );

1.5 upwards

# This snippet prevents new registrations from anonymous users
# (Sysops can still create user accounts)
$wgGroupPermissions['*']['createaccount'] = false;

• Note: New users will still be able to be created by sysops, in the following manner:

Go to [[Special:Userlogin]], when logged in as a sysop. The link to this page differs from language, (f.ex. in Dutch it is [[Special:Userlogin]]). Enter a username and an email address, and click the "by email" button. The account will be created with a random password which is then emailed to the given address.

• Note: It may be appropriate to edit the text displayed when a non-user attempts to log in. This can be done at [[MediaWiki:Nosuchuser]], when logged in as a sysop. Use plain text without any special formatting; as the formatting is ignored and the text is literally rendered.

Disable anonymous edits

• By adding the following line to LocalSettings.php, it is possible to entirely disable anonymous edits:

Pre-1.5

# Entirely disable Anonymous Edits in Wiki versions 1.4 and before
$wgWhitelistEdit = true;

Note that you have to add this to the end of the LocalSettings.php file, just above the closing "?>" for it to work properly.

1.5 upwards

# This snippet prevents editing from anonymous users
$wgGroupPermissions['*']['edit'] = false;

Users will still be able to read the page and can view the source by using Special:Export/Article name.

Note that you have to add the above entry below the line:

require_once( "includes/DefaultSettings.php" ); 

for it to work properly.

Disable anonymous reading

Pre-1.5

• If you want anonymous users not to be able to read or edit your MediaWiki, add this line to your LocalSettings.php:

# Pages anonymous (not-logged-in) users may see
$wgWhitelistRead = array( "Main Page", "Special:Userlogin", "Wikipedia:Help" );

This way anonymous users can only see the Main Page, the user login page and the help page.

Caution: if your MediaWiki is in a language different than English, you need to translate the titles in the array. For instance, in Spanish the line will look like this one:

 $wgWhitelistRead = array ("Portada", "Especial:Userlogin", "-", "MediaWiki:Monobook.css",
                                                                          "MiWiki:Ayuda");

For more esoteric languages, for which your editor and PHP parser might be in disagreement over file encoding, you could use the PHP urldecode() to input the page names. For example in Hebrew you could use:

#                              "Special":Userlogin (in Hebrew)                    
$wgWhitelistRead = array( urldecode("%D7%9E%D7%99%D7%95%D7%97%D7%93:Userlogin"),
#                                "MainPage" in Hebrew
                          urldecode("%D7%A2%D7%9E%D7%95%D7%93_%D7%A8%D7%90%D7%A9%D7%99") ) ;

Also in some non-esoteric languages you might need to encode the special characters, like ő.

You may find more information about user access restriction on Setting user rights in MediaWiki

1.5 Upwards

In order to prevent readings from anonymous users you need to set (in /LocalSettings.php):

# Disable reading line, for anonymous (not-logged-in => * ) :
$wgGroupPermissions['*']['read'] = false;

# ... and enable anonymous to read the followings pages :
$wgWhitelistRead = array( "Main Page", "Special:Userlogin", "-", "MediaWiki:Monobook.css" );

# ... same in an other language (French, with one UTF-8 special characteres) :
# $wgWhitelistRead = array( "Page Principale", "Special:Userlogin", utf8_encode('Aide en français')); 

• The second allows users to view the main page and log in. Without this line, no one can log in.
• If page names have more than one word, use space " " between them, not underscore "_" . See French example : "Page principale".

• In addition to the main page of such a private site, you could give access to the Recentpages page (if you think that its content isn't private) for feed readers (like Mozilla firefox) by adding "Special:Recentchanges" in the WhitelistRead.

• To prevent a special page from being listed at [[Special:Specialpages]], edit SpecialPage.php and change the relevant entry to be an instance of UnlistedSpecialPage instead of SpecialPage.

• If your navigation sidebar contains sensitive information, like project names in the links, you may disable the sidebar for anonymous users by editing includes/Skin.php and changing the function buildSidebar(). Add these lines near the very top, after the globals.

global $wgUser;
if (! $wgUser->isLoggedIn()) {
        return array();
}

See also: Help:User levels, Page access restriction with MediaWiki, and Hidden pages

To allow access to maintenance scripts run on the command line, use this technique in LocalSettings.php:

if ($wgCommandLineMode) {
        $wgGroupPermissions['*']['read'] = true;
}

Preventing access to some SpecialPages

According to what is mentioned on Writing a new special page, you need to make changes in DefaultSettings.php as well as in SpecialPage.php. If, for example, you only want normal registered users see the Specialpage "Specialpages", which lists all specialpages, you need to do the following:

The changes recommended for DefaultSettings should actually be put in LocalSettings

In Specialpage.php you change: THAT PHRASE DOESN'T EXIST IN Specialpage.php (1.8.2)

'Recentchanges'     => new SpecialPage( 'Recentchanges'),

THAT PHRASE DOESN'T EXIST IN Specialpage.php (1.8.2) to:

'Recentchanges'     => new SpecialPage( 'Recentchanges', 'onlyuser'),

and in DefaultSettings you need to define "onlyuser":

$wgGroupPermissions['user']['onlyuser'] = true;

This assigns all users the new generated "onlyuser"-right.

Alternatively to simply restrict access to users who have edit permission, change to:

'Recentchanges'     => new SpecialPage( 'Recentchanges', 'edit'),

There is no need to modify DefaultSettings in this case.

Note: If you create your own user right (e.g 'onlyuser' above) and you restrict the viewing of certain Special pages to that user right, then it will not show up in the list of SpecialPages! This is because the SpecialSpecialPages code iterates thru the $wgAvailableRights array contained in includes/Defines.php and matches up the rights in that array with what the user has... If it's not listed in the array, then regardless of whether the user has the right assigned via the $wgGroupPermissions['user']['onlyuser'] = true; statement in LocalSettings.php, the page will never show up in the listing under either the "Available to all users" or the "Restricted..." sections of the page... The solution is to edit the includes/Defines.php file and insert your custom right into the array...

This probably isn't the preferred method, and there's probably some way to add it in via LocalSettings.php but after a few hours of tracking down this buglet, I just wanted the thing to work so I could go home and get some food-like substances... If a developer has a better way, please edit my entry :->

Edit:: Instead of directly editing includes/Defines.php I would suggest adding the following line in LocalSettings.php:

$wgAvailableRights[] = 'userright';

replacing 'userright' with your custom right. Ideally, a mechanism would be provided to accomplish this with a function call.

Setting permissions for a Group on a whole new Namespace

When you want to create limited access to part of your Wiki, the easiest way is by setting permissions for a Group (for information about group rights refer to this page) on a whole new Namespace. It is possible to do this with existing namespaces, but be careful.

You can also set up access permissions in a convenient way with the help of NamespacePermissions Extension. This should be attempted — it is much easier than the following instructions.

1. Create new namespace

In the new version of MediaWiki (1.7.), there will be an option to add/remove namespaces. For now, you can do it manually. (HowTo...) Note that the howto suggests to add your new namespace to $wgNamespacesToBeSearchedDefault but if you want to forbid users to see your namespace this is a *BAD* idea as people can find bits of your content in the search results!

2. Change file Title.php (includes/Title.php)

You will have to change a few lines in Title.php inside the userCanRead() function (a few more lines are included for orientation).

Word viewforbidden is a custom-named right, as are read or write or delete right. You can read more about rights on User rights.

Title.php (old)

 if( $wgUser->isAllowed('read') ) { 
   return true;
 } else {
   global $wgWhitelistRead;

Title.php (new)

   if( $this->getNamespace() == 100 ) {
       return $wgUser->isAllowed('viewforbidden');
   }
   if( $wgUser->isAllowed('read') ) { 
       return true;
   } else {
       global $wgWhitelistRead;

Please note that the '100' internally represents a custom namespace. If you have created multiple custom namespaces, then please use the appropriate number here.

See also : Help:Custom_namespaces

3. Change file LocalSettings.php

You have to add one line to LocalSettings.php.

$wgGroupPermissions['groupname']['viewforbidden'] = true;

If you already have a custom group, you can change 'groupname' to whatever you want.

If you do not already have a custom group, one can be created by adding a line to LocalSettings.php.

$wgGroupPermissions['your new group name']['edit'] = true;

4. Avoid transclusion

'Restricted' pages can still be transcluded using '{{:RestrictedNS:Pagename}}' To avoid that pages on this namespace can be used as templates, add the following line to LocalSettings.php (needs 1.10alpha)

$wgNonincludableNamespaces[] = 100;

5. Explanation

Only users that belong to the group that has the permission viewforbidden can read namespace 100 that you have defined first.

This was successfully tested on a MediaWiki 1.6.3 and MediaWiki 1.8.2

Note

• Anonymous users can find these pages, along with a text-preview, by using the Search function
  • This can be prevented by denying anonymous users read access to Special:Search

Restricting access to any page

Depending on the task, there are different solutions:

page protection for different user groups

• Page protection for single pages (read and/or edit): Page Protection Extension
  

Allows you to define different user groups and grants access to one or multiple users and one or multiple groups. (June 28: works only with 1.6.3 through 1.6.6)

• I used the function fnMyUserCan shown below in the questions section but it didn't work properly - for one thing, strpos() was being used on an object rather than a string. strpos() didn't complain, but luckily I tried using stripos(), which did. A bit of searching found out how to get the namespace and so I now support the following (using 1.6.7):

1. No access for anonymous users apart from the main page, help and login.
2. Only DEV users can see and edit articles in namespaces 104/5.
3. CSS users can see articles in CSS (100/1) and ISG (102/3) namespaces, but only edit those in CSS.
4. ISG users as for CSS, but can only edit articles in ISG namespace.
5. All users can update User and User Talk, but only PUB users can update other "public" pages.
6. Project:Protected Page was updated to explain all this malarkey!
7. Enrolment is only allowed by Sysops.

with these changes:

1. LocalSettings.php:

	$wgNamespacesWithSubpages = array(
		(snip)
		NS_CATEGORY_TALK  => true,
		100               => true,
		101               => true,
		102               => true,
		103               => true,
		104               => true,
		105               => true
	 );

	$wgNamespacesToBeSearchedDefault = array(
		NS_MAIN           => true,
		100               => true,
		101               => true,
		102               => true,
		103               => true,
		104               => true,
		105               => true
	);

	# This snippet prevents new registrations from anonymous users
	# (Sysops can still create user accounts)
	$wgGroupPermissions['*']['createaccount'] = false;

	# This snippet prevents editing from anonymous users
	$wgGroupPermissions['*']['edit'] = false;

	# Pages anonymous (not-logged-in) users may see
	# This way anonymous users can only see the Main Page, the user login page and the help page.

	$wgWhitelistRead = array( "Main Page", "Special:Userlogin", "-", "MediaWiki:Monobook.css" );
	$wgGroupPermissions['*']['read'] = false;

	# 060721 Updates for Namespace group permissions below here.
	# See also updates to includes/Title.php.
	# Instructions taken from http://meta.wikimedia.org/wiki/Preventing_Access#Setting
                                         _permissions_for_a_Group_on_a_whole_new_Namespace

	$wgGroupPermissions['CSS']['editCSS'] = true;
	$wgGroupPermissions['ISG']['editISG'] = true;
	$wgGroupPermissions['DEV']['editDEV'] = true;

	function fnMyUserCan($title, $user, $action, $result)
	{
		$ns = $title->getNamespace();
		if ($action != 'edit') {
			$result = true;
		} elseif ( (($ns == 100) || $ns == 101 ) and ! $user->isAllowed('editCSS') ) {
			$result = false;
		} elseif ( (($ns == 102) || $ns == 103 ) and ! $user->isAllowed('editISG') ) {
			$result = false;
		} elseif ( (($ns == 104) || $ns == 105 ) and ! $user->isAllowed('editDEV') ) {
			$result = false;
		# Allow users to edit User and User talk.
	  	} elseif ( (($ns == 2) || $ns == 3 ) ) {
	    		$result = true;
		} elseif ( $user->isAllowed('editPUB') ) {
			$result = true;
		} else { # Catch-all:
			$result = false;
		}
		} else {
			$result = true;
		}
	}
	$wgHooks['userCan'][] = 'fnMyUserCan';

2. includes/Title.php:

	/* 060721 Update for Namespace group permissions.
	 * See also changes to LocalSettings.php.
	 * Lines below replaced as per
	 * http://meta.wikimedia.org/wiki/Preventing_Access#Setting_permissions_for_a_Group_on_a_whole_new_Namespace
	 */
		/*      if( $wgUser->isAllowed('read') ) {
		 *	      return true;
		 *      } else {
		 */	     global $wgWhitelistRead;
	/* by this: */
		 if( $wgUser->isAllowed('read') ) {
			if( ( $this->getNamespace() == 104 ) || $this->getNamespace() == 105 ) {
				if( $wgUser->isAllowed('editDEV')  || $wgUser->isAllowed('viewDEV') ) {
					return true;
				} else {
					return false;
				}
			} else {
				return true;
			}
		} else {
			global $wgWhitelistRead;
	/* end of replacement code. */

Andthepharaohs 14:27, 2 August 2006 (UTC)

page protection for one user group (hidden pages)

Allows to define exactly one tag for hidden pages, which can be seen by one or more user groups. But it is not possible to define a page that can be seen by only user group A while another page can only be seen by user group B. Use is limited. You can achieve similar results with protected namespaces.

Jerome Combaz has an excellent patch for Mediawiki that only allows members of specified groups to view or edit individual pages. This is probably of more interest to intranet applications, but it's something that I'd like to see as part of the main install. See Page_access_restriction_with_MediaWiki or follow this link for the patch and an explanation

page protection using security definitions

The PageSecurity extension allows the use of security definitions and protection expressions to restrict read and write access to set of pages by user groups.

Preventing access to all pages for non-validated users

If you want a wiki that is accessible only to certain users (i.e. an internal wiki site that is accessible from the Internet), you can restrict all actions for anonymous users, including reading, by adding this into your LocalSettings.php:

$wgEmailConfirmToEdit=true;

// Implicit group for all visitors
$wgGroupPermissions['*'    ]['createaccount']   = true;
$wgGroupPermissions['*'    ]['read']            = false;
$wgGroupPermissions['*'    ]['edit']            = false;
$wgGroupPermissions['*'    ]['createpage']      = false;
$wgGroupPermissions['*'    ]['createtalk']      = false;

// Implicit group for all logged-in accounts
$wgGroupPermissions['user' ]['move']            = false;
$wgGroupPermissions['user' ]['read']            = false;
$wgGroupPermissions['user' ]['edit']            = false;
$wgGroupPermissions['user' ]['createpage']      = false;
$wgGroupPermissions['user' ]['createtalk']      = false;
$wgGroupPermissions['user' ]['upload']          = false;
$wgGroupPermissions['user' ]['reupload']        = false;
$wgGroupPermissions['user' ]['reupload-shared'] = false;
$wgGroupPermissions['user' ]['minoredit']       = false;

// Implicit group for accounts that pass $wgAutoConfirmAge
$wgGroupPermissions['autoconfirmed']['autoconfirmed'] = true;

// Implicit group for accounts with confirmed email addresses
// This has little use when email address confirmation is off
$wgGroupPermissions['emailconfirmed']['emailconfirmed'] = true;

// Permission to change users' group assignments
$wgGroupPermissions['bureaucrat']['userrights'] = true;

// Group for all logged-in accounts who had their email confirmed and have been
// accepted as readers.
$wgGroupPermissions['wikireader' ]['move']            = false;
$wgGroupPermissions['wikireader' ]['read']            = true;
$wgGroupPermissions['wikireader' ]['edit']            = false;
$wgGroupPermissions['wikireader' ]['createpage']      = false;
$wgGroupPermissions['wikireader' ]['createtalk']      = true; # Your choice here
$wgGroupPermissions['wikireader' ]['upload']          = true; # Your choice here
$wgGroupPermissions['wikireader' ]['reupload']        = true; # Your choice here
$wgGroupPermissions['wikireader' ]['reupload-shared'] = true; # Your choice here
$wgGroupPermissions['wikireader' ]['minoredit']       = false;

// Group for all logged-in accounts who had their email confirmed and have been
// accepted as editors.
$wgGroupPermissions['wikieditor' ]['move']            = true;
$wgGroupPermissions['wikieditor' ]['read']            = true;
$wgGroupPermissions['wikieditor' ]['edit']            = true;
$wgGroupPermissions['wikieditor' ]['createpage']      = true;
$wgGroupPermissions['wikieditor' ]['createtalk']      = true;
$wgGroupPermissions['wikieditor' ]['upload']          = true;
$wgGroupPermissions['wikieditor' ]['reupload']        = true;
$wgGroupPermissions['wikieditor' ]['reupload-shared'] = true;
$wgGroupPermissions['wikieditor' ]['minoredit']       = true;

You will also want to add this line:

$wgWhitelistRead = array ( "Main Page", "Special:Userlogin", "Special:Preferences",
"Special:Confirmemail", "Special:Userlogout", $wgSiteName.":Help", "MediaWiki:Monobook.css",
"-" );

in order to allow users to see the main page, the login page and create a new account page, as well as the user's preferences and confirm e-mail address pages.

The problem I ran into with MediaWiki v1.7.1 is being unable to confirm my e-mail address when I create a new user. I can access the login page and create an account, I can access my preferences to update my e-mail address, I click on Confirm e-mail and receive the e-mail, but when I click the link, I get a "You must log in to view other pages." message. In order to allow everyone to see the "Special:Confirmemail" and "Special:Confirmemail/xxxxxxxxxxxxxxxxxxxxxxxxxxxxx" to verify the e-mail, you need to add four lines to include/Title.php: find the function userCanRead() and add just before these lines, which are at the end of the function)

 }
return false;
}

the following four lines:

$names=split("/", $name);
if(strcmp($names[0],"Special:Confirmemail")==0 && count($names)==2 && preg_match('/[a-f0-9]{32}/',$names[1])) {
  return true;
}

The final code should look like this:

$names=split("/", $name);
if(strcmp($names[0],"Special:Confirmemail")==0 && count($names)==2 && preg_match('/[a-f0-9]{32}/',$names[1])) {
  return true;
  }
 }
return false;
}

Questions

Question: Is it possible pass credentials within the RSS/ATOM Feed URL?

.

Question: Is it possible to restrict access to (certain) images in a wiki?

Answer: Yes. Please see above first and then change the Title.php in something like

           if( $wgUser->isAllowed('read') ) { 
                        if( ($this->getNamespace() == 152)||($this->getNamespace() == 153)_
_||(($this->getNamespace()==6)&&(strstr($this->getDBkey(),"forbidden")!=false)) ) {
                                return $wgUser->isAllowed('viewforbidden');
                        } else {

Question: I would like one or more sections of a page to be protected while leaving the rest of the page unprotected and freely editable. Is this possible?

Answer: Yes, but it might be a pain. Make the sections of the page actually whole other pages, then transclude them onto the main page where they're combined, eg. Create pages Section A and Section B, then on page C put {{Section A}} and {{Section B}}. Put edit links (like template:edit) on the pages/sections you want to be editable, then protect everything else (probably including page C as well otherwise they could just blank it).

Question: Does disabling anonymous reading/access, in both 1.4/1.5x prevent google (and other search engines) from indexing the aforementioned now 'blocked' wiki pages?

Answer: If an anonymous user can't access a page search engines won't be able to either.

Question: I want it so only registered users can edit the page itself but still allow general (anonymous) access to Discuss this page/Post a comment. Can this be done?

Pre 1.5 Answer: No, you need to upgrade to 1.5 or above.

1.5 Answer: Yes. See Here.

Question: I want to allow all images to be seen but not necessarily all pages. Can this be done in 1.4.9?

Question: I want anonymous users to be able to view the wiki source on any page, without giving editing access. Is this possible?

Answer: For version 1.6.7, in LocalSettings.php add:

function fnMyUserCan($title, $user, $action, $result) 
{
  if (($action == 'edit') && $user->isAnon())
    $result = false;
}
$wgHooks['userCan'][] = 'fnMyUserCan';

You do not need to add $wgGroupPermissions['*']['edit'] = .. to LocalSettings.php (it makes no difference if the above code is added).

Comment: I tried using the above, but it didn't work. See Preventing_Access#page_protection_for_different_user_groups above for a version that does (for me, anyway!)

Question: I want a user to have only the permission to edit one specified page on the wiki. Is it possible?

Simplre answer: Yes. Set read to false, and edit to TRUE! Then, put the page you want them to be able to edit in the read whitelist. They will be unable to see, and thus unable to edit, any page other than the one in the whitelist.

Comment: Sorry but this is not realistic... What if you want your user to be able to see many pages but edit just one of them? And what if you have different users in this case? (the whitelist is common!) I feel like the mediawiki does not handle user permissions properly (I mean, these don't seem to have been designed on a unix like permission scheme which would have however solved everyone's problems...).

Advanced answer: Define $wgWhitelistEdit as an array of pages everybody can edit, eg. $wgWhitelistEdit = array("Talk:Main Page", "Wikipedia:Sandbox"); and add the following function:

function wgWhitelistEdit($title, $user, $action, $result) 
{
        if ($action == 'edit')
        {
                if ($wgWhitelistEdit&& in_array($title->getText(), $wgWhitelistEdit))
                        $result = true;
        }
}

$wgHooks['userCan'][] = 'wgWhitelistEdit';

Question: Is it possible to allow anonymous users to view an entire wiki, and allow them to edit one specific page, while prohibiting editting of any other page by anonymous users?

Question: I want to permit anonymous edits only for specified IPs (in CIDR form, preferably). Is it possible ?

Question: I want different logged in users to be able to edit different pages. Is this possible?

All Versions Answer: Yes, the following patch creates groups for restricting pages and viewing restricted pages. This means you can have one set of users that have acess to one set of pages, everyone else can't see them. The author plans to extend it to incorporate multiple groups with multiple restrictions. Page access restriction with MediaWiki

Question: I want to require new users to have a valid email address when they create a new account. Then I can restrict new users to those who have an email address that matches a certain pattern. This way only users within my organization will have access to the wiki. Is there a way to require users to receive their initial password via email?

1.5 Answer: If you want to create users only by e-mail, in your LocalSettings.php you have to write $wgEmailAuthentication = true;. For matching the e-mail with some pattern I think that you have to modify the php.

I have 1.5.8 and setting $wgEmailAuthentication = true; doesn't seem to do anything with regard to new users requiring a valid e-mail when they create an account? In fact "Fields marked with superscripts are optional" with a superscript "*" in the email field is the message I get on the create account page and I can still create an account without entering an e-mail address.

You also have to set $wgEmailConfirmToEdit = true;.

Feedback: Sorry, that does not seem to work in 1.6.7 I put

$wgEmailAuthentication = true;

$wgEmailConfirmToEdit = true;

in LocalSettings.php and I can still create accounts without entering an email. Is anything wrong with that or changed in 1.6.x? Thanks!

Feedback: I'm using 1.6.7 and added those two lines:

$wgEmailAuthentication = true;

$wgEmailConfirmToEdit = true;

On the LocalSettings.php and it is indeed working, so new users can't edit any page until they confirm their email, so registering isn't enough anymore. However, the email field on the registration page is still marked with '*', so it still states it is optional. I'm now editing this PHP to remove the * sign from the registration page, however, this still won't help much since I prefer not to change too much on the PHP to validate if the user actually entered an email address. Anybody knows if there is a way to clear the 'validating' users list automatically if a user didn't confirmed his account within X days? So it won't grow on the databases on the long run?

Thanks for any help with this! Amit Regev.

Edit the following page to remove the '*': MediaWiki:Youremail

Question:I want to impede anonymous users to have access to talk pages and special pages, without having to do a large whitelist, is it possible?

Question:I want anonymous users to be able to read only some determinated pages but not all the wiki, and being unable to edit the whole wiki, is it possible?

Question:Is it possible to have certain areas only editable by people with a corresponding permission level, and have other areas viewable but not editable (to those with a lower permission level)?

This can be done with semi-protection. Just protect the pages you don't want edited, and select block unregistered users. Normally, users automatically become registered after their account reaches a certain age (by default 0), but you can change that so that need to be put in a group; i.e.

$wgGroupPermissions['autoconfirmed']['autoconfirmed'] = false;
$wgGroupPermissions['registered']['autoconfirmed'] = true;

Question: I want to block anonymous users from seeing anything except the front page (I already know how to do this Setting user rights in MediaWiki) but create an account that I can give to certain people which only allows them to view all the pages on the site, not edit, how can I manage this? (Using Version 1.5.7)

Wrong Answer: I imagine you could create a group for them and allow that group to view, not edit.

$wgGroupPermissions['mygroup' ]['read'] = true; $wgGroupPermissions['mygroup' ]['edit'] = false;
This doesn't work, since group permissions are additive, e.g. the user will still be in the group user which is allowed to edit pages.

Answer: The simpliest way is to create an user, then block him infinitly, he will be read-only.

Correct Answer: Instead of trying to deny the edit permission, you need to create a group called e.g. 'editor' and only grant the edit permission to those who need to be able to edit instead.

$wgGroupPermissions['user']['edit'] = false;

$wgGroupPermissions['user']['createaccount'] = false;

$wgGroupPermissions['editor']['edit'] = true;

Question: I want to restrict some pages from anonymous browsing.

Answer: Answering my own question, this is an hour long hack to tie "protected read" permissions to a category. YMMV offer not valid in all 50 states.

$ diff mediawiki-1.6.3/includes/Title.php w/includes/Title.php 
1085c1085
<               if( $wgUser->isAllowed('read') ) {
---
>               if( $wgUser->isAllowed('read') && $wgUser->isAllowed('protected') ) {
1087a1088,1097
>                       if ( $wgUser->isAllowed('read') ) {
>                               $categories = $this->getParentCategories();
>                               //print_r( $categories);
>                               if ( is_array($categories) && array_key_exists('Category:Protected',$categories) ) {
>                                       //echo "no read";
>                                       return false;
>                               } else {
>                                       return true;
>                               } 
>                       }

$wgGroupPermissions['user']['protected'] = true;

Question: How do I reset the WikiSysop password if I get this message:

Error sending mail: There is no e-mail address recorded for user "WikiSysop".

Answer: here or here

Question: Can I reset the Sysop username?

Answer: See Renameuser extension.

Question: Is it possible to make it so that only the page creator can edit a certain group of pages?

Question: How would I redirect anonymous users to the login page without allowing them to see the main one?

Answer: Okay, got the basic functionality working myself. Remove "Main Page" from the $wgWhitelistRead array, and it redirects to the "you need to log in" page. But I'd prefer for it to go directly to the login page. And I'd want to get rid of all the "Create" messages.

Question: After disabling anonymous edit permission, I get ther error session_fail_preview. What did I miss ?

Question: Is it possible to make it so that anyone below sysop can only edit in the Talk namespace?

Answer: I expect you could use a variation of this Users:PyneJ:Hacks:PageWhiteList.

Feedback: I tried this using 1.6.7 but could not get it to work.

Answer: Try using a 'hook'. See mw:User:Barrylb/Usercan Hook.

Feedback: Perfect. Thank you.

Question: I have a question regarding the topic "Setting permissions for a Group on a whole new Namespace" above. How should I alter the code to make more than one namespace hidden? In the example the custom namespace applied to namespace 100 can only be read by a certain group. I have two custom namespaces so far, one defined as namespace 100 and its talk page as namespace 101. How do I make namespace 101 hidden as well? I tried using the above example, but with the second line replaced with:

if( $this->getNamespace() == (100 AND 101)){

as well as with:

if( $this->getNamespace() == (100 OR 101)){

and was able to hide both pages, but then my ability to log out was disabled while using these variations. Can anyone provide any help? Thanks in advance.

Answer:This seems a typical error in the code. (100 AND 101) or (100 OR 101) returns either "true" or "false". So your code means:

if( $this->getNamespace() == false){ // because (100 AND 101) is false

This is not what you want.

Try this instead:

if( $this->getNamespace() == 100 OR $this->getNamespace() == 101) {

Question: Is it possible to disable all page edits, including sysops, not just anonymous users?

Answer: In LocalSettings.php add a $wgGroupPermissions setting for each user group, eg $wgGroupPermissions['sysop']['edit'] = false;

Question: I've setup a Custom Protected Namespace as in "Setting permissions for a Group on a whole new Namespace" above. But anonymous users could still see the content via Special:Export and Special:Recentchanges?feed=xml. For a workaround I patched Export.php and SpecialRecentchanges.php, too. Is there a cleaner way?

Question: Is there a way where Wiki can authenticate users from the active directory versus users trying to create new accounts? Also is there a way to approve or deny access to Wiki and give no access to anyone till membership is approved?

Answer: The answer to the first part is a resounding yes, check out LDAP Authentication. As for the second part, it is perhaps easiest to create an Active Directory group for wiki users and control memebership from there (instructions can be found in the previous link).

Question: I want to ban certain user from editing certain page but admit him to edit all other pages. Please tell me how to do that?

Question: I saw Wikipedia can ban users who registered less than 4 days, how did it do that?

Answer: You can do this by adding $wgAutoConfirmAge = 3600*24*4; to your LocalSettings.php, where '4' is how many days you want to do.

Question: Is it possible to prevent direct access to image media (via /.../images/mediaitems.jpg type links)? I use a XAMPP installation on a Windows server.

Question: Can you make it so users are not allowed to create new pages, but are allowed to edit pages? I'd like to make it so admins have to create a page, but then any one can edit it.

Answer: Simply set $wgGroupPermissions['*' ]['createpage'] = false;, $wgGroupPermissions['user' ]['createpage'] = false; and $wgGroupPermissions['sysop' ]['createpage'] = true;.

Question: How do you make a group of pages viewable by anyone, even the unauthenticated?

Answer: If you just have one or two pages then you can white list them with wgWhiteList, but if you have a whole bunch that must coexist with private pages, change userCanRead() function in includes/Title.php to include the following test for the substring PUBLIC. Clearly, you can use any substring you choose. Your pages that have the substring PUBLIC will be viewable by anyone. I inserted this code after the check of the wgWhitelistRead.

                       if ( preg_match("/PUBLIC/", $name)) {
                               return true;
                       }

Question: Is it possible to prevent access to certain parts of a page (eg a simple link or button in the skin) to certain groups? I've tried if ($wgUser->isSysop()){ echo "hello"; } but that thows up an error: Call to a member function isSysop() on a non-object.

Question: Is it possible to restrict access to history pages?

Question: I am using WikiMedia version 1.8.2 how can I hide the History tab for a specific group while allowing the group members to edit the pages(sky)?.

Question: I would like to make certain pages available to a range IPs, and block access to the rest of the Wiki. Is it possible ?

Question: Is it possible that a user can edit his/her own userpage but not of others?

Question: Is it possible to create a user group that has the same setting as the default group but cannot use the redirect command?

Question: Is it possible to have two classes of anonymous (not logged in) user, one of people using the intranet (in my case they should be able to view pages and create accounts) and one for people using the intranet (in my case they should not be able to view pages or create accounts)?

Question: Is it possible to remove the "view source" tab for users who are restricted to edit a page? (We use the restriction patch "Restrict pages under MediaWiki" from Jérôme Combaz version 1.6.8)

---

Other Wikis with user rights management

It should be pointed out, that other wikis provide this function.

• MoinMoin
• GroupWikiBase based on MediaWiki (limited documentation, small project)
• TWiki