Manual talk:Preventing access

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:

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

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

function toplinks ... if ( 0 != $wgUser->getID ) { $s .= $sep. $this->editThisPage ... function bottomlinks ... if ( 0 != $wgUser->getID ) $s .= ' '. $this->editThisPage. ' '; ...
 * skin.php*

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

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.

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

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


 * Be using MediaWiki 1.6alpha
 * Install the ConfirmEdit extension and configure it to throw a captcha on account creation
 * Install the FancyCaptcha plugin
 * Run the python script to generate captcha images


 * The extension, plugin and script, as well as MediaWiki 1.6alpha, are all available from CVS.

Question
When I set these lines in localsettings.php: ###  #   # $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?
 * 1) Permission keys given to users in each group.
 * 2) All users are implicitly in the '*' group including anonymous visitors;
 * 3) logged-in users are all implicitly in the 'user' group. These will be
 * 4) combined with the permissions of all groups that a given user is listed
 * 5) in in the user_groups table.
 * 1) This replaces wgWhitelistAccount and wgWhitelistEdit
 * 1) The following line should be commented, otherwise these settings will
 * 2) throw away the settings on DefaultSettings.php (you probably don't want this).
 * 3) With this line commented you will only overwrite the settings you explicitly
 * 4) define here (that's what you probably want).
 * 5) $wgGroupPermissions = array;

Answer
Figured it out hehe - my line was actually: which set the group permissions, including sysop, to none. Commenting out that line left me fine again -- &#8465;ilver&#167;&#8465;ide 17:22, 5 January 2006 (UTC)
 * 1) $wgGroupPermissions = array;

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:

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)
 * 1) Protect user namespace

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 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 =  PAGENAME =  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, 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)

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)

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)

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

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)

Disputed anonymous user viewing
From Manual:Preventing access: "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)

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)

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)

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)

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 [[Image:Tournesol.png|20px]] 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)

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

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)

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. -- Skiz zerz  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. -- Skiz zerz  00:53, 22 August 2008 (UTC)
 * NHF, thank you for explaining versioning to me in short! --Borislav Dopudja 22:55, 29 August 2008 (UTC)

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?

Prevent viewing of wiki markup/code
How? --78.180.49.220 07:28, 3 September 2008 (UTC)

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). -- Skiz zerz  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)

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 ( 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)

Dosn't seem to work
I've been trying to disable read access by anonymous users. I've added the code to the LocalSettings.php file and nothing seems to happen. I can still see every page when not logged in. I also tried adding the account creation line suggested and it isn't working either. I tired adding some random letters to the top of the LocalSettings.php file just to confirm that it is the right file, and it broke the wiki, so it is working. I just can't seem to figure out why those lines are having no effect. Any ideas?
 * Add the code at or near the bottom of the file, not the top. —Emufarmers(T 10:49, 6 April 2009 (UTC)
 * Thats what I did, and I removed the <? as well, and I can still access all the pages as a anon. sfeild@uark.edu
 * You mean ?>, right?
 * The only thing I can suggest is that you paste the contents of your LocalSettings.php file (with passwords removed) so I can look for a problem. —Emufarmers(T 20:21, 6 April 2009 (UTC)