Manual talk:Preventing access

From MediaWiki.org

Jump to: navigation, search

Contents


The following discussion has been transferred from meta.wikimedia.org.
 Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).


[edit] Disable the login page?

I use external authentication for mediawiki...works perfectly.

To limit access I have restricted editing of pages to only logged in and have restricted account creation to sysops. Good so far.

Since authentication takes place before they even get to the wiki, I want to restrict access to the login page since it isn't needed - is that possible? I would be happy with a method of redirecting to my website login page.

I did try using .htaccess, but couldn't get it to work, so hoping there is an "internal" solution.

[edit] Are there any plans to add more admin features to mediawiki?

I would like to have a wiki, but I've had so many problems with spammers that it made it not worth my time. I'd like to make it so all users have to register to post (which I've found how to do), and then I would like to be able to ban accounts, block ip addresses, and block out countries like Russia and a few others. I would also like to make it so anonymous email addresses like yahoo, hotmail and gmail wouldn't be allowed, since these are the ones that spammers tend to use. I run several large discussion boards, and by just reading through registered users before you grant them access, you can eliminate spam by 99%. Is there anyway to add this on to mediawiki?

[edit] Help I broke my Wiki, now my critics say Wiki is sicky!

[edit] Initial action that broke my wiki:

All I had wanted to do was limit access to anonymous users to edit pages. I found the following and put it into the LocalSettings.php.

# This snippet prevents editing from anonymous users

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


BJ----------- I think you need to add the following

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

I did this and it works for me, allows logged in users to edit but not anonymous ones.

[edit] Results:

After that change went into effect, no user can see any non special page. The source of the Main_Page is as follows for all users:

<html><body></body></html>

[edit] Special Pages are OK:

The blank page is all normal pages, however, if I type the URL exactly, the users can access all special pages like Special:Listusers for example.

[edit] I tried to fix it by doing this:

If false broke it, then true should fix it. So I typed the following into LocalSettings.php:

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

[edit] Time to cry:

I didn't work. This is bad. My critics have been putting in pages, now they can't access anything so me and my wiki reputation is on the line. So in a panic, I resarched the problem and found even more options to add, so I added these lines to LocalSettings.php.

$wgGroupPermissions['*']['createaccount']   = true;
$wgGroupPermissions['*']['read']            = true;
$wgGroupPermissions['*']['edit']            = true;
$wgGroupPermissions['*']['createpage']      = true;
$wgGroupPermissions['*']['createtalk']      = true;

No luck, I'm in deep.

[edit] HELP:

Any help is greatly appreciated!!! I'm trying to get this system on-line at work, and several critics are going to use this booboo as a weapon against wiki technology. Several have created pages so I don't want to start over from scratch.

Thanks Barry for responding, I rewrote this to make it very clear.

Cwhitedog 16:54, 14 July 2006 (UTC)

Suggestion: try installing another copy of MediaWiki somewhere else, and retrace your steps, trying to reproduce the problem, keeping a copy of any changed files along the way. Then you may see what caused the problem and hopefully fix it... Good luck! -- Barrylb 07:55, 15 July 2006 (UTC)

[edit] Security Problem using Namespace to limit access

I found a problem with using the Namespace approach to limit access to certain groups of people (method with changes to Title.php). It works in general. However, if you create a redirect in a non protected page that redirects to the 'hidden' page, the page is still displayed.

[edit] Security Problem 2: it's possible to see text from protected pages when searching

Don't include the protected namespace in $wgNamespacesToBeSearchedDefault in LocalSettings.php. If you do, all users (even those not logged in) are able to make a search including pages within the protected namespace. The search result page shows text from protected pages.

Users which are not included in the protected user group are also able to log in and choose to search in the protected namespace, and viewing protected text.

Question: It should not be too difficult to exclude those Namespaces from the Search Selection? Like edition title.php, there must be a place for scanning user rights before building the search selection bar.

How to prevent unauthorized users to search on protected namespaces?
Andershhh 13:14, 25 July 2006 (UTC)

Using NamespacePermissions_Extension does not solve the above, but is easier than using the method in Setting permissions for a Group on a whole new Namespace.
Andershhh 12:13, 27 July 2006 (UTC)

[edit] Non-latin languages

Describing anything non-latin as 'esoteric' is just silly. Klingon is esoteric, Chinese is not. Anyone mind if we change it?

[edit] Whitelisting

How come, when I add the "$wgWhitelistRead =" as instructed, an anonymous use can still view the contents of pages beyond main/login/help? I copied/pasted the line from this page to avoid the possibility of a typo. - Gregg S.

wgWhitelistRead seems to have no effect in 1.4beta1. From what I can tell, this is due to the default settings of the groupRights hash located in includes/User.php, in the isAllowed function, line 625. Changing line from

 'read'          => '*',

to

 'read'          => 'user',

seems to fix the problem. Joel Franusic 209.129.63.92 22:29, 8 Dec 2004 (UTC)

I'm looking at the FAQ and see the following entry

Question: I want to be tyrannical (just registered users can edit) on the page itself, but still allow general access to Discuss this page/Post a comment. Can this be done? Answer: No. This feature was requested for http://wikimediafoundation.org, but has not yet been implemented.

However, it appears that this feature has infact been implemented for wikimediafoundation. Is this feature in the 1.3.9 code base? If so, how does one activate this feature?

Thanks! Damien Heiser

It appears that this feature has not (yet, I hope) been implemented on the Foundation wiki. Brianjd 10:38, 2005 Jan 24 (UTC)

I though for a second that Brian was wrong, and even emailed the Foundation to ask them for the code, but if you click on the "discuss" tab you do not see a discussion but rather a link to a general feedback page. Alas.
It seems that someone has posted a bug AND a patch to achieve this see this bug. I managed to apply the patch (or at least half of it) but i am no good with preg_match. I used

$wgWhitelistEdit = array ('/Talk:*/'); but it did no work. Talk: pages are still off limits.


This is the correct statment to fix it. You need to apply This Patchthen add this line to LocalSettings.php.

$wgWhitelistEdit = array ('/Talk:/i');

This is Tested and Working in 1.4.6. Users:PyneJ:Hacks:PageWhiteList

Has anyone got the $wgWhitelistAccount, $wgWhitelistEdit and $wgWhitelistRead settings working as instructed? I've edited the LocalSettings.php file to no effect. I'm using version 1.3.11

-- Andy 23 Feb 05

[edit] Couple dumb questoins

1. Can I set Main to be sysop-only, leaving Talk (and User space) to be open?

Basically I would want Main to act like MediaWiki: space does now, where the entire namespace is protected by default.

2. Can I set uploads such that it is sysop-only, or will I need a custom Special:Upload?

KeithTyler 19:48, 4 Mar 2005 (UTC)

Question-request help :

I would like to allow only few user to login and edit the pages and i want to allocate their user names and passwords, is it possible?, if possible could any provide the procedure? many thanks in advance

Srikanth

No such thing as dumb questions....only dumb people who ask them ... (and can't spell questions)!

[edit] Question regarding SysOp creation of new accounts

When adding the following line in the LocalSettings.php:

Specify who may create new accounts: 0 means no, 1 means yes
$wgWhitelistAccount = array ( 'user' => 0, 'sysop' => 1, 'developer' => 1 );

the "create an account or log in" page still has sentences regarding the creation of an account. Can those be changed/eliminated to reflect the fact that that page only allows for log in? If yes, how?

Thank you.

[edit] Why doesn't wgWhitelistEdit work the same way as wgWhitelistRead?

I notice that wgWhitelistRead can actually be an array containing a list of exceptions to the read access block. But despite having a similar name, wgWhitelistEdit cannot be used that way.

Question: I want to be tyrannical (just registered users can edit) on the page itself, but still allow general access to Discuss this page/Post a comment. Can this be done?

The above *could* be done, if:

  1. wgWhitelistEdit worked like wgWhitelistRead
  2. they accepted wildcards/REs

Neither seems terribly involved, though the latter might have a minor performance hit when used.

Then you could do:

$wgWhitelistEdit = array ("Talk:.*");

- KeithTyler 20:43, 24 Mar 2005 (UTC)

I guess this can not be done? This seems to be essential to allow MediaWiki to be used as a blog or any other personal website. Seems to be a massive hole in the WikiMedia functionality. Any ideas on how this can be done?
And while we are about it, any ideas on how to exchange ideas? because I am not going to know if you (Keith, or anyone else) respond! (I will make a link to this page on my wiki and check back. But how do MediaWiki-ers exchange ideas normally? Forums? Notifications??! User:Tim
Generally by making a point of checking back and reviewing their watchlist. Wiki is not the best option for a full featured forum. I personally wish someone would make a good Wiki of MW quality with an integrated and full-featured forum, but this has apparently not occured to anyone. - 67.51.210.122 22:22, 4 May 2005 (UTC)
The best way to do this would be with Postnuke integration! This is a feature that I would GREATLY like to see. It would allow integration with a forum (through pnPhpBB2 etc.) and several other nice features, and the user access rights can be set on a page by page basis, so if the user rights from postnuke were integrated, you could say that every page with Private* are restricted to members of group X etc, and postnuke can handle setting up the groups up for you. Having coded some postnuke modules, this sort of user controll is VERY easy, just a simple "if current user has rights to do X" check, the rest of the "why" they have the rights is handled for you by postnuke.

I was thinking that something similar the other way round could work... make all users that you want to allow to edit "main" pages into sysops, and protect all pages from edits... also edit the messages referring to protected pages to make it sound less unusual. Would that be feasable? 213.232.66.5 00:37, 11 May 2005 (UTC)

Ok... I figured out a way to do it if you don't mind editing index.php. Add the following lines to index.php just after it sets $title:
 if ( strpos( strtolower($title), "talk:" ) + 4 == strpos( $title, ":" ) ) {
   $wgWhitelistEdit = false;
 }
This will match any Talk: or Xyz_talk: etc. page, but not TalkTalk or Namespace:Talk etc. Hope this helps -- 213.232.66.5 01:39, 11 May 2005 (UTC)
If you're running a non-English MediaWiki, you have to substitute "talk:" with the localized term, e.g. "Diskussion:" in German. --MaPhi 08:26, 2005 May 12 (UTC)

I read around a bit on access restrictions, and decided I wanted to be able to choose between a blacklist and a whitelist. Since the current system didn't allow that, I scrapped the $wgWhitelistRead and $wgWhitelistEdit variables and made my own.

$wgBlockAnonRead = false;   # true = users must login to read.
$wgBlockAnonReadEx = array( 'User Clubhouse');   # Pages exempted from the read policy.
$wgBlockAnonEdit = true;   # true = users must login to edit.
$wgBlockAnonEditEx = array( 'Talk:*', 'User talk:*');   # Pages exempted from the edit policy.

It also required some modifications to Title.php, User.php, EditPage.php and Parser.php to replace the old variables. The example given here would let anonymous users read all pages except User_Clubhouse in the main namespace, and edit all pages in the Talk: and User_talk: namespaces, but nowhere else. I chose to keep it simple, so the wildcard feature only works for "Namespacename:*" to (dis)allow an entire namespace. It didn't take much time, and it works great for my wiki. Dashiva 22:25, 18 May 2005 (UTC)

This page: Regexp_wgWhitelistRead did the trick for me.

[edit] Differing access restrictions

In case anybody has ideas, I would like to implement two sets of access restrictions:

  1. people on a specific set of IP addresses (the "inside") can edit, and view anonymously
  2. people on other addresses (the "outside") must log in to view and edit the wiki. -- Kowey 17:29, 1 Apr 2005 (UTC)

[edit] Solution

I know this is a REALLY late response but I made a simple fix to do this. Edit the LocalSettings.php file:

if(substr($_SERVER['REMOTE_ADDR'],0,11) != '123.123.123') {
 $wgGroupPermissions['*']['read'] = false;
 $wgGroupPermissions['*']['edit'] = false;
}

Everyone outside of 123.123.123.x will end up without the ability to read/edit the pages. Whilst people that are within the 123.123.123.x range will not get those settings and therefore can read/edit anon. :D

[edit] Thanks

Thanks for that! Just so you know, it's never too late! I was forced to revisit the issue much later, this time to completely restrict write access to anybody outside a certain IP range. My implementation:

if(substr($_SERVER['REMOTE_ADDR'],0,8) != '123.123.') {
   $wgGroupPermissions['*']['edit'] = false;
   $wgGroupPermissions['*']['createaccount'] = false;
   $wgGroupPermissions['user' ]['edit'] = false;
}

Cheers, -- Kowey 07:57, 1 March 2007 (UTC)

[edit] Creating Restricted Areas / Virtual Wiki spaces

Question: I would like to allow certain individuals that are logged in to visit all pages except those that would be set in a restricted area. Another group of logged in users would be able to only see their restricted area of pages (like managers in a company). Does this kind of user/group administration exist yet? If not, is there some other way to implement it other than having to install a separate copy of MediaWiki in a different server directory and a create a separate database? Tim Ingalls 4 Apr 2005

There are two hacks in development for that. See Hidden pages and Page access restriction with MediaWiki for details. I don't know if either will ever be merged into MediaWiki. --MaPhi 10:33, 2005 May 4 (UTC)


[edit] Restricting Account Creation

Is there any way I can make it so that only registered users can create new acounts? And not just sysops either, I want ordinary users to be able to create these accounts also, but not anonymous ones.

-- I have the version 1.5.7. of mediawiki and it seems odd to me that if we restrict the account creation, it also restricts the logging procedure (because both are on the same page, and that this page is unreachable when account creation is restricted. Is there anyway to know how wikimedia and mediawiki websites have separated this two process, and if it solves the problem ? --

[edit] Only show edit links if logged in

I wanted to only show the edit links once you were logged in. I made the changes below and by also using the Whitelistedit option I can then control who edits. I am a novice mediawiki hacker so I know there is a better way of doing this, but it worked for me!

Where ever there is an "Edit this Page" option, wrap it with a check for user being logged in. For me this involved changes in

  • skin.php*
 function toplinks
 ...
 if ( 0 != $wgUser->getID() ) {
  $s .=  $sep . $this->editThisPage()
 ...
 function bottomlinks
 ...
 if ( 0 != $wgUser->getID() ) 
   $s .= '' . $this->editThisPage() . '';
 ...
  • cologneblue.php* (you may not have this, depends on template you are using)
  function quickbar
  ...
  if ( $wgOut->isArticle() ) {
    if ( 0 != $wgUser->getID() ) {
      $s .= $this->menuHead( "qbedit" );
      $s .= "" . $this->editThisPage() . "";
  ...
  • title.php* (to hide the section edit links on the side of the page)
   function userCanEdit() {
   global $wgUser;
   if ( $wgUser->getID()==0 ) { 
      return false;
   }
   return $this->userCan('edit');
   }

Phoebebright 14:07, 20 Jun 2005 (UTC)

Question: Has anyone found an updated way to do this for 1.6/1.7? I couldn't get any of this to work. I don't allow edits by non-logged in users, and being able to hide the edit link from the top of the page would save them having to see the "you must be logged in" page.

[edit] Allowing access only to Special:Userlogin in 1.5

[edit] Question

I have just installed 1.5 and am now having trouble with read access. I set

$wgGroupPermissions['*']['read'] = false;

So now when an anonymous user goes to my site they get prompted:

Login Required
From MyWiki

You must login to view other pages.

Return to Main Page.

However, when you click the login link, the login page is blocked and it tells me I need to login again. How can I add Special:Userlogin to a "whitelist" in 1.5?

- broox - 10:19, 18 Oct 2005

[edit] Answer

I figured this out 4 minutes after posting, haha. So to help someone else... $wgWhitelistRead still works in 1.5. Here are some lines from my LocalSettings.php.

This does not allow anonymous users to read, edit, or create accounts. The only page they can view is: Special:Userlogin

$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgWhitelistRead = array ("Special:Userlogin");

[edit] Email Verification/Graphical Security Confirmation for Account Creation

[edit] Question

How can I allow only users with working e-mail addresses to create new accounts? Is there a way to require a bitmap security confirmation before creation of the account?

To install a captcha for account creation, you need to
  1. Be using MediaWiki 1.6alpha
  2. Install the ConfirmEdit extension and configure it to throw a captcha on account creation
  3. Install the FancyCaptcha plugin
  4. Run the python script to generate captcha images
The extension, plugin and script, as well as MediaWiki 1.6alpha, are all available from CVS.

[edit] Admin broke...

[edit] Question

When I set these lines in localsettings.php:

###
# Permission keys given to users in each group.
# All users are implicitly in the '*' group including anonymous visitors;
# logged-in users are all implicitly in the 'user' group. These will be
# combined with the permissions of all groups that a given user is listed
# in in the user_groups table.
  #
# This replaces wgWhitelistAccount and wgWhitelistEdit
  #
# The following line should be commented, otherwise these settings will
# throw away the settings on DefaultSettings.php (you probably don't want this).
# With this line commented you will only overwrite the settings you explicitly
# define here (that's what you probably want).
#$wgGroupPermissions = array();
$wgGroupPermissions['*'    ]['createaccount']   = true;
$wgGroupPermissions['*'    ]['read']            = true;
$wgGroupPermissions['*'    ]['edit']            = false;
$wgGroupPermissions['user'    ]['createaccount']   = true;
$wgGroupPermissions['user'    ]['read']            = true;
$wgGroupPermissions['user'    ]['edit']            = true;

It breaks the admin - as in, admins no longer act as admins. they cannot ban, see admin functions in Special:Specialpages or whatever it is, they cannot protect pages or edit protected pages, anything. however, they still appear in the userlist as admins... when I comment out the lines, admins work again. what's with this?

[edit] Answer

Figured it out hehe - my line was actually:

#$wgGroupPermissions = array();

which set the group permissions, including sysop, to none. Commenting out that line left me fine again -- ℑilver§ℑide 17:22, 5 January 2006 (UTC)

[edit] Preventing anon access documentation error?

If I added the following to LocalSettings.php

$wgGroupPermissions['*'    ]['createaccount']   = false;
$wgGroupPermissions['*'    ]['read']            = false;
$wgGroupPermissions['*'    ]['edit']            = false;
$wgWhitelistRead = array ("Main Page", "Special:Userlogin");

in MediaWiki 1.5.5, then I kept getting page errors when not logged in. By digging through the errors in the FireFox console, it looks like the Main Page is referencing other resources in the wiki space. I fixed the errors by changing $wgWhitelistRead to

$wgWhitelistRead = array ("Main Page", "Special:Userlogin", "MediaWiki:Monobook.css", "-");

Can anyone confirm this? If this is true, then docs should be updated accordingly.


Comment

When I added the two lines suggeted on this page:

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

I was getting JavaScript errors on the Main Page. It seems that adding: "MediaWiki:Monobook.css", "-" to the array list has solved the problem. Thanks for the info.

For easy reference the entries in my LocalSettings.php file now look like:

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

Comment 2

When I add the next line in the german version:

$wgWhitelistRead = array( "Main Page", "Special:Userlogin");

There was no possibility to login anymore. You must change this to:

$wgWhitelistRead = array( "Main Page", "Spezial:Userlogin");

It would be nice, we have a standard interface (english possible), so that all user use the same commands.

Buschhardt

[edit] Clarity is Awful on this Page for 1.5x users

It is extremely unclear what one must do in order to prevent anonymous visitors from editing a 1.5x website based on the information provided by the page. I'm a fairly sharp guy, but if I were to go by the information here, I'd be pulling my hair out with trial and error on a live website. If you're going to include all the other options (preventing reading access, preventing new user signups, etc), then there needs to be a full discussion about it so that people are clear what they need in particular for their needs! People aren't psychic and will not off-hand be able to determine where one feature starts and another begins.

IMPORTANT: Most people will not want to change anything other than to make it a requirment to be a registered and signed in user to edit a page. It's an easy instruction for 1.4x users...let's repeat that ease for 1.5 users. Please!

[edit] Restricting uploading to sysops or bureaucrats

Is there any way to do this without editing the usergroups thing in 1.5, because thats a bit over my head. --68.151.180.89 05:42, 4 March 2006 (UTC)

No. But it's a one-liner.
$wgGroupPermissions['user']['upload'] = false;
Dah-dum!


What about preventing Printing for non-logged-in users? i've tried a lot of stuff, but i think is have a thinking problem...

$wgGroupPermissions ['*']['printable'] or ['print'] = false --> doesn't work

then i tried to edit the monobook.php--> for example if $wg UserGroups = 'user' -->(then show the print link)...but it didn't work...why i dont' know. I know that $wgUserGroups seems to be an array i also treid $wgUserGroup[]!=null...then i tried a while loop, i didn't programmed it right or it didn't work again...i kinda lost, because admin speeker corners are rare in the net... thanks a lot for help jules

[edit] Preventing edits to User: pages by other users

Someone on #mediawiki gave me this useful code snippet, to be added near the top of userCan in Title.php:

 # Protect user namespace
                if( $action == 'edit' ) {
                        if( $this->mNamespace == NS_USER && $this->mTextform == $wgUser->getName(
) ) {
                                return( true );
                        } else {
                                 return( false );
                        }
                }

24.125.100.198 05:05, 9 April 2006 (UTC)

I have applied this code to my MediaWiki 1.6.6 installation. I have successfully restricted the edit command on User: pages to the owner. But unfortunately, it also happen to the User_Talk namespace. When I investigate the code, the $this->mNamespace variable return the same code for discussion or User_Talk edit link. Is this a bug?
Semut 15:01, 27 May 2006 (UTC)

I have modified the code to meet my need. I add this code snippet after if( $action == 'create' ). Now my wiki installation prohibit user to edit other user page in USER namespace. Hope it useful.

                if( $action == 'edit' ) {
                        if( $this->mNamespace == NS_USER && !$this->isTalkPage() && $this->mTextform != $wgUser->getName() ) {
                                return( false );
                        }
                }

Semut 06:41, 31 May 2006 (UTC)

[edit] How to change the LOGIN REQUIRED TO EDIT page?

I would like to make this page look more friendly, but can't work out how to change it!

Cheers

[edit] Hide recent changes in "Setting permissions for a Group on a whole new Namespace"

This works for me, but it might of broken something I don't know about, so use at your own risk. If your implementing Preventing_Access#Setting_permissions_for_a_Group_on_a_whole_new_Namespace and don't want it to show up in recent changes to users not allowed to view the page, to SpecialRecentchanges.php just before:

"# Namespace filtering $hidem .= is_null( $namespace ) ?  : ' AND rc_namespace' . ($invert ? '!=' : '=') . $namespace;"


I added this:

"if( $wgUser->isAllowed('viewforbidden') ) {} else { $hidem .= ' AND rc_namespace != 100'; $hidem .= ' AND rc_namespace != 101'; }"

And it hide changes to the hidden namespace from users not allowed to view it (including anon users). (Of course Page_access_restriction_with_MediaWiki might be more up your street if you want to hide it from everyone.) Implemented in Mediawiki 1.6.5


[edit] Namespaces but how?

"Only users that belongs to the group that has the permission viewforbidden can read namespace 100 that you have defined first."
So how can I get pages to belong to a namespace 100? I don't really understand the concept.
I want only users, that I manually put into a Group, to be allowed to view the wiki-content (as it is private). How is the best way to achieve it? Thx for help!


I understand from the article that you create pages with the namespace:pagename naming convention, and they're automatically in the similarly-named, predefined group.

You can check to see if a given page is in a group by editing the following into a page, and previewing it:

    NAMESPACE = {{NAMESPACE}}
    PAGENAME = {{PAGENAME}}
    FULLPAGENAME = {{FULLPAGENAME}}

--209.213.214.226 17:10, 7 June 2006 (UTC)

In the LocalSettings.php file you define the new namespaces like this:

$wgExtraNamespaces =
       array(100 => "Atlas",
             101 => "Atlas_talk"
             );

So now you have the new namespaces Atlas and Atlas_talk. To get pages into the new namespace, you can either move an existing article (click on the move tab, Move page: Somepage then To new title: Atlas:Somepage) or you can create a new page, just being sure to prefix the title with the new namespace (i.e. Atlas:New_page) --Lafnlab 02:29, 7 July 2006 (UTC)


In Create new namespace I read "In the new version of MediaWiki (1.7.), there will be an option to add/remove namespaces" - I've installed V1.8, so where's this option? And: What happens in your example, if I simply move "SomePage" to "Atlas:Somepage" without defining the Namespace? (I tried, at least I don't get any error message). And: Where and how do I define that anonymous users may read everthing, but not the articles in Namespace "Secret" (as an example)? --Ralfiii 12:46, 17 October 2006 (UTC)

[edit] Creating custom user groups

Regarding namespace restriction, it mentions a way of restricting access using namespaces but there doesn't seem to be any information on actually creating a custom group. I have looked everywhere, on this site and on google, but have not found a single shred of informtion on this. Could someone explain how this is done ?

--213.219.161.124 12:57, 10 June 2006 (UTC)

It was so obvious, I overlooked it too. You have to define the new group in the LocalSettings.php file, along with the permissions. I think even if you only list one permission, MediaWiki will create a new group. As an example:
$wgGroupPermissions['hoboken']['edit'] = true;

then you would have a new group called hoboken that can edit pages. Following that, you should be able to go to the Special:Userrights page and find the new group. --Lafnlab 02:11, 7 July 2006 (UTC)

[edit] Quick Note about Preventing_Access#1.5.x

Preventing_Access#1.5.x says: "In 1.5, in order to prevent readings from anonymous users you need to set (in /includes/DefaultSettings.php):" Aren't all changes supposed to be made in LocalSettings.php? The wording suggests that this change should be made in DefaultSettings.php instead. Just wanted to bring this to someone's attention...

138.88.204.75 15:46, 14 June 2006 (UTC)

[edit] Error Message after Title.php changes (Fixed)

I am using the 1.8CVS on my server and after applying the Title.php changes to make the hidden namespace work, I get the following error when not logged in and trying to view a hidden page:

Fatal error: Call to a member function getLatest() on a non-object in /home/taacus/public_html/includes/SkinTemplate.php on line 817

The patch works when logged in I can see the pages, but those not logged in get the error message above instead of a nice message that they must be logged in.

This is the chunk from SkinTemplate.php:

// A print stylesheet is attached to all pages, but nobody ever
// figures that out. :)  Add a link...
if( $this->iscontent && ($action ==  || $action == 'view' || $action == 'purge' ) ) {

$revid = $wgArticle->getLatest();
if ( !( $revid == 0 )  )
$nav_urls['print'] = array(
'text' => wfMsg( 'printableversion' ),
'href' => $wgRequest->appendQuery( 'printable=yes' )
);

Due to my lack of PHP knowledge, I have no hope of fixing it myself. Any help that anyone can provide would be great.--Kf4bdy 04:02, 15 August 2006 (UTC)

This error is fixed with the most recent commit on SVN. --Kf4bdy 07:42, 19 August 2006 (UTC)

[edit] Broken with 1.9 (Fixed)

As we move toward the eventual release of mediawiki 1.9, I feel I should mention that this hack does not work with the 1.9 branch. I hope someone will start working on a fix before 1.9 is released and everyone is left out in the cold. --Kf4bdy 21:24, 4 November 2006 (UTC)

With the most recent changes to the code, [1] this works with the 1.9CVS again. Thanks. --Kf4bdy 05:30, 7 November 2006 (UTC)

[edit] HELP with the Namespaces

Here is my situation:

  • Wiki has been running for months; only I can assign usernames
  • Only logged-in users can edit or read pages
  • We're trying to move some pages to the "Public" namespace (104).
  • Those pages should be non-editable; but the "Public talk" namespace (105) should be editable by anonymous users.

I cannot get the namespace fix to work. Also, any time I edit the Title.php, the look of the wiki gets a little funny (fonts are larger, etc.).

So, the question is: How can I allow users to edit my "Public talk" namespace only?

Thank you Timneu22 20:00, 7 November 2006 (UTC)

[edit] Help with groups

Hi to all! I'm trying to set on my mediawiki group permission to some page (you can edit/read only if you are a member of a particular group). I have tried many extension, but i'm a bit confusing about using group. Where can i create a group? Where can i associate a user to a group? how to close reading/modifying to a group. Thanks in advance! :D

Answer: create a new group

[edit] Multiple Image namespaces?

I use custom namespaces to run a wiki with three different protection domains - "open" to anyone (default namespace), a "private" domain using one of the custom namespaces and an "admin" domain only available to the admins using a second custom namespace.
Works perfectly for page content and disussion pages. However, we also have a lot of files, pdf's, doc's, etc. that also sorts into those three protection domains.
Now, the problem is, of course, that all files go into the special Image namespace. Ideally, I'd like to split that into three namespaces, similar to how it works for the discussion pages for custom namespace pages.

Has anyone done this or anything similar? Ideas are welcome!

[edit] Disableing New Registrations

I have added the code that prevents new people from making accounts, but I have a couple questions:

One: How can new accounts get made for people? Two: How can I make it so only the admins can do that?--TheSikso 06:46, 28 December 2006 (UTC)

[edit] Preventing access to Specialpages

Hello! I have tried to prevent access to the Specialpage "Specialpages" as shown under Preventing Access#Preventing access to some SpecialPages, especially the shorter alternative to restrict access there only to registered users (me :-) ), but me newbie (to mediawiki and php *sigh*) does not find out how it works. Used 1.8.2 and 1.7.1, but did not find any entries like the mentioned one - where have I to put it? -- 85.212.175.102 21:39, 13 January 2007 (UTC)

Well, try and error :-). Put an 'edit' command to most of the specialpages in the list "static public $mList" in SpecialPage.php, including "Specialpages". Hope, this will work :-). -- 85.212.173.98 21:31, 16 January 2007 (UTC)

[edit] Changes to Title.php cause wiki to crash

Using v.1.7.1

Adding following lines (in includes/Title.php)


  if( $this->getNamespace() == 100 ) {
      return $wgUser->isAllowed('viewforbidden');
  }


before the following (existing) lines:


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


causes wiki to crash (main page does not appear);

Any suggestion? 147.197.251.136

[edit] Help...getting hacked (sort of)

So I've got this obnoxious user who just won't back off. I had to disable anonymous editing, then also force e-mail confirmation. However, the 'user' keeps registering new accounts. He is using one of those spam domains (spam.la) so that he can 'confirm' himself, then wreak havoc on my wikis. Any way, I can hack the user creation process to prevent users from being created @a.certain.domain like spam.la?

Personally, I have used it (spam.la) in the past, but never for just causing someone who is running a personal wiki or other sites trouble. I just don't want to keep receiving SPAM for registering at some website or other.

Any ideas?

Thanks,
24.127.37.76 05:41, 16 February 2007 (UTC)

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.

[edit] Prevent Category Changes

I'd like to restrict the ability to add, remove, or change a page's category to sysops only, while still permitting the rest of the text to be edited. Can anyone suggest a good starting point to implement this? --216.86.81.31 03:24, 14 May 2007 (UTC)

There is no built-in support for that. To do that, you would need to heavily modify MediaWiki. Titoxd(?!?) 05:18, 14 May 2007 (UTC)
Or at least do a reasonable amount of hacking, at least if you want to make it foolproof. It shouldn't be impossible to get a diff of categorylinks, but there's certainly no built-in functionality for this. —Simetrical (talk • contribs) 00:33, 15 May 2007 (UTC)

[edit] Admin Approval

Hi, everyone. I'm trying to make a Wiki for my site, but since it's a really big site, I need a tool that, when the users edit the pages, the edit is sent to an admin page, and the admin can allow if the page will be edited or not.

Is there any possible way to do this in MediaWiki?

No, somewhat related would be Extension:FlaggedRevs. Aaron 21:04, 29 May 2007 (UTC)

[edit] Prevent new user accounts, but now I can't log in

I've added $wgGroupPermissions['*']['createaccount'] = false; to the LocalSettings.php but now nobody can log in!!! PD: I'm on 1.69

[edit] Business Wiki

BizzWiki is a set of extensions & patches to a Mediawiki installation for enhancing the permission functionality. Have a look at BizzWiki.

[edit] Restrict editing but allow "view source"

Is this possible? I want to do this for anonymous users. Ideally, the "Edit" tab/link text should be replaced with "View source", as it is on protected pages and for those users banned from editing altogether. -Eep² 23:44, 21 July 2007 (UTC)

I'm using this: $wgGroupPermissions['*']['edit'] = false; -Eep² 12:45, 22 July 2007 (UTC)

[edit] Disputed anonymous user viewing

From Manual:Preventing access#Restrict viewing of all pages:

Note: if you want anonymous users to be unable to view the wiki, you should not allow them to edit any page (see #Restrict editing of all pages above).

This is incorrect. As stated in the previous section by me, I have denied editing to anonymous users but they can still view non-editable pages (which is every page). -Eep² 02:36, 24 July 2007 (UTC)

When you edit a page, you can see all the wiketext and preview it, which would defeat much of the purpose of not allowing non-users to view pages. Aaron 10:24, 26 July 2007 (UTC)
It should be reworded then to say "wiki markup", because "wiki" is a general term for an entire wiki website. But what I am trying to do is to not allow editing pages but still allow "view source" that happens with protected pages. I don't want to have to protect every page/category/whatever in order to allow "view source"... -Eep² 12:35, 26 July 2007 (UTC)

[edit] Security hole on password protected wikis

Hi, I just found out that even if you disable viewing pages for non logged in users one can still acess the uploaded media files when entering the direct URL. Is there a way to give only access to logged in users to download media files? --83.228.136.57 19:04, 7 August 2007 (UTC)

Yes, see Manual:Image Authorisation. --Dmdwiggi 21:31, 14 August 2007 (UTC)

[edit] Restrict editing for certain IP ranges

The section labeled "Restrict editing for certain IP ranges" isn't too helpful. As it says there (at present) :

Schools and other institutions may want to block all edits not from a few specified IP address ranges. To do so, all other ranges must be blocked. The only way to do this at present without modifying the code is to go to Special:Blockip and systematically block every one of the 65,536 CIDR Class B ranges that you don't want to be able to edit.

Period, no other info. How does one do this, exactly? I am almost led to conclude from the text here that one would have to explcitly type in 65,535 numbers (for all Class B's except one's own) to achieve the desired access restriction -- and I only say "almost" because that's so insane I can't believe it's the real intent. It's irritating that this is the manual page for this feature, but provides no practical, useful information.

I'm sure someone reading this knows the answer -- how about adding a little text to explain how to do the thing being discussed. Again, this is the manual, folks.

The point, I presume, is that it is not feasible in MediaWiki. —Pathoschild 23:30:01, 06 September 2007 (UTC)
With SQL access to the database, is there an SQL query or two that can be run to accomplish this? That would probably be the best way at present. 131.111.228.219 00:25, 20 November 2007 (UTC)

[edit] forbidding deleting text, allowing adding new text

how can i forbid deleting text from a discussion page, but allow writing new text? because i don't want any wiki user to edit any comments left on discussion page --85.141.88.147 17:33, 19 September 2007 (UTC)

You probably can't. Except by using a bot that finds and reverts deletion of comments on discussion pages.131.111.228.219 00:23, 20 November 2007 (UTC)

[edit] Hide revision history?

Hi folks, is it possible to hide the revision history from anonymous users? -- Bartmoss 13:47, 18 January 2008 (UTC)

Not without preventing them from reading the wiki in its entirety. --Skizzerz talk - contribs MediaWiki Support Team 17:57, 18 January 2008 (UTC)
Too bad. Thanks for the reply. Is this something that would makes sense to submit as a feature request? I envision this to be really useful where a Wiki is maintained by a closed user group, but publicly readably. -- Bartmoss 07:51, 21 January 2008 (UTC)

[edit] how to distinguish edit rights between page and talk

I'm looking for a chance to enable creating and editing talk pages to everyone while allowing ordinary article editing only to registered users. --A.Heidemann 20:20, 14 February 2008 (UTC)

Talk pages are in a different namespace. So, see Manual:Preventing_access#Restrict_editing_of_an_entire_namespace -- Duesentrieb ⇌ 20:48, 14 February 2008 (UTC)
sorry for beeing blind - just discovered it myself too.  :-(
Many thanks for that quick answer! --A.Heidemann 21:57, 14 February 2008 (UTC)

[edit] Keeping blocked users from reading

We have an installation of 1.6.7 configured like mentioned here here. Is there any way, to prevent blocked users from reading, when they log in? Maybe a better one, than changing their password and email address. --Flominator 08:54, 10 April 2008 (UTC)

Update: I have found this thread at mwusers.com that offers a way to do it. Any simpler ones? --Flominator 06:39, 15 April 2008 (UTC)

The one mentioned in the link looks quite complex, so we decided to stick to changing email and password in the database. --Flominator 17:25, 15 May 2008 (UTC)

[edit] Math, decimals

It seems to me that some people don't know math well. Decimal number especially.

Version 1.9 is NOT prior to version 1.1

--Borislav Dopudja 11:29, 20 August 2008 (UTC)

You sir, fail. First of all, I agree with you. Version 1.1 did come before version 1.9. However, version 1.10 is the version that was released after version 1.9. This is because the version numbers are not decimals. If you knew anything about versioning and software development, you would know this already. Apparently you don't. So go educate yourself before you ask any more questions about this. --Skizzerz 14:42, 20 August 2008 (UTC)
Well, I certainly did not know about your versioning system – I apologize for my ignorance. On the other hand, this is actually the first time I've noticed this scheme, as programs I’ve had opportunity to work with version decimally. As there is quite a possibility that there are a lot more users like me who don't know about versioning scheme you use, it might be useful to add some note somewhere where such users would encounter it. --Borislav Dopudja 11:13, 21 August 2008 (UTC)
It's used very widely, at least among open-source software. The current stable Linux kernel version is 2.6.26. The current version of GNOME is 2.22. MySQL is 5.0.67, Apache's 2.0 and 1.3 branches are at 2.0.63 and 1.3.41. lighttpd is at 1.4.19. The individual levels of version number mean different things: MediaWiki 1.6.10 is 1.6.0 with ten separate patch releases, while 1.7.0 is a totally different release, snapshotted in the first place about three months later. —Simetrical (talk • contribs) 17:23, 21 August 2008 (UTC)
Wow... a day later when I read that comment... I really sounded like an ass. I apologize for coming down on you like that, your question was perfectly valid for someone who isn't versed in how software and such gets developed, and I really have no excuse for calling you a few things that I did. As for the note, we could probably link the word "version" to the Wikipedia article somewhere, I suppose. --Skizzerz 00:53, 22 August 2008 (UTC)
NHF, thank you for explaining versioning to me in short! --Borislav Dopudja 22:55, 29 August 2008 (UTC)

[edit] How does $wgWhitelistRead work?

I am using MW Ver. 1.13 german. My LocalSettings.php looks like this:

$wgGroupPermissions['*']['read']                = false;
$wgGroupPermissions['user']['read']             = true;
$wgGroupPermissions['sysop']['read']            = true;

$wgGroupPermissions['*']['edit']                = false;
$wgGroupPermissions['user']['edit']             = false;
$wgGroupPermissions['sysop']['edit']            = true;

If the $wgWhitelistRead is empty, I shouldn't see the login page, but I can. Why? I set $wgWhitelistRead to the following value:

$wgWhitelistRead = array ("Hauptseite");

Now, if not logged in, you can see the page called Hauptseite, but also the login page? Will say:
With this $wgWhitelistRead I actually have access to the login page. But I shouldn't have. So what's wrong?

[edit] Prevent viewing of wiki markup/code

How? --78.180.49.220 07:28, 3 September 2008 (UTC)

[edit] Tricky Question

Dear Friends,

I got a question. Please excuse if explained before, but it seems tricky to me. I am not quite familiar with Mediawiki-intallations at the moment. Please let me know some suggestions.

I want to use a Wiki to organise the cooperation in my company, but we need a more familiar platform. It is possible to restrict alot of user-rights, of course. But we are looking for a way to define a set of specific PCs to access the Installation. I do not mind a range of IPs or providers, but a set of 20 specific computers, located around the world.

Example: If a given computer has a cookie (or something) on its drive, it should be usable to login and access the Wiki. If not, no user should be able to log in. Even if he is already registered.

Any ideas? --92.117.87.167 18:08, 15 October 2008 (UTC)

You could probably modify your Apache (or IIS or whatever webserver you use) configuration so that it only allows access from those pcs/IPs and everyone else will be denied. If you want the other people to still be able to read your wiki, however, then a bit more coding would be required to safely do this (cookies can be spoofed, so I'd recommend against that). --Skizzerz 21:28, 15 October 2008 (UTC)
The limitation of IPs can not be used.
Cookies would be fine. Is it possible to make an installation, that does not open any site without a cookie? Is there someone who can explaind hot to do it? :-) --92.117.181.171 18:49, 16 October 2008 (UTC)

[edit] Editing talk pages only

I'm using MediaWiki 1.13.2, and have successfully disabled editing for all anonymous (*) users as described here. Now I want logged-in users (users) to be able to edit and create talk pages, but not the main namespace, and it looks like $wgNamespaceProtection will help, but I can't figure out how. Can someone help.

Additionally, I have successful created a new usergroup, "editors" that can edit the main namespace ($wgGroupPermissions['editor']['edit'] = true; in LocalSettings.php) but I don't want people in "editors" to be able to edit the talk name space. Is this possible? (ie. users can edit talk pages, but not main page; editors can edit main pages, but not talk pages.) --84.9.191.165 16:01, 12 November 2008 (UTC)

Retrieved from "http://www.mediawiki.org/wiki/Manual_talk:Preventing_access"
Personal tools