Manual talk:Preventing access

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.

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?

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.


 * 1) This snippet prevents editing from anonymous users

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

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:

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.

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:

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

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.

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)

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.

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)

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

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

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.

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

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

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.

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

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

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!

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!

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)

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)

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)

Quick Note about Preventing_Access
Preventing_Access 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)

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)

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, this works with  the 1.9CVS again. Thanks. --Kf4bdy 05:30, 7 November 2006 (UTC)

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)

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

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!

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)

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)

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

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)

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)

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

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)