Manual talk:Preventing access/Archive 1

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

Archives done on april 2009 during MW 1.15.alpha dev.

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.

This could be useful as well. Ksd5 23:06, 10 October 2009 (UTC)

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)

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

Solution with CIDR

Here is a solution that uses CIDR matching so you can better utilize Access Lists. For example you can do net_match($_SERVER['REMOTE_ADDR',"10.0.10.64/28") to add extra access for that range.

function net_match($ip,$mask)
{
$ai=explode(".",$ip);
$tmp=explode("/",$mask);
$bf=($tmp[1]) ? (int)$tmp[1] : 32;
$am=explode(".",$tmp[0]);
while($bf>7)
  {
  $i=(int)array_shift($ai);
  $m=(int)array_shift($am);
  if($i!=$m)
    return false;
  $bf-=8;
  }
if($bf==0)
  return true;
$bf=8-$bf;
$bf=255<<$bf;
$i=(int)array_shift($ai);
$m=(int)array_shift($am);
$i=$i&$bf;
return ($i==$m) ? true : false;
}

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)

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)

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 ? --

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.

Allowing access only to Special:Userlogin in 1.5

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

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");

Email Verification/Graphical Security Confirmation for Account Creation

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.

Admin broke...

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?

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)

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

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

There is no way to prevent a user from printing a website. It may be possible to remove "Printable version" from the toolbox, but the user can still click File | Print. 24.214.233.83 12:56, 21 May 2009 (UTC)

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)

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

• On your wiki, edit MediaWiki:Whitelistedittext and MediaWiki:Whitelistedittitle -- Barrylb 15:45, 1 July 2006 (UTC)

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

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)

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)

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)

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.