Manual talk:Preventing access

How diffs could be visible again in the RSS or Atom feeds ?

In Manual:Preventing access#Restrict viewing of all pages it is said that :

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

But the problem is that since MediaWiki 1.12, as soon as "Disable reading by anonymous users" is set, the diffs aren't shown anymore in the feeds.

How come ?

How diffs could be visible again in the RSS or Atom feeds ?

--Dieudo 00:20, 10 January 2011 (UTC)

+1. I'm having the same problem, after preventing access for non-registered users to view articles, RSS feeds only display the title, having to click on the link and log in to be able to see the diff files.

Is there a way to solve this? Thanks in advance. --84.233.177.18 16:48, 26 July 2013 (UTC)

writeapi

Ohmygod Manual:$wgEnableWriteAPI and the writeapi permission is true by default, but not one word is mentioned about the API. Say if spammers can directly use the default wide open writeapi permission to spam away unthwarted? Jidanni 08:23, 22 January 2011 (UTC)

Right. Just as they could use the regular edit interface. —Emufarmers^(T|C) 23:26, 22 January 2011 (UTC)

So locking it down should be mentioned just as much as locking down the corresponding regular edit interface, please. Jidanni 00:09, 23 January 2011 (UTC)

If you've removed the edit right from a group, they won't be able to edit through the write API either. —Emufarmers^(T|C) 00:51, 23 January 2011 (UTC)

That's good to know. Jidanni 01:02, 23 January 2011 (UTC)

"Consider whether MediaWiki is right for you" redux + Restrict viewing page to registerred or handpicked person

Greetings from Norway.

I have also ended up dumbfounded by this wording and in particular because MediaWiki IS right for me and all my organisations. I don't understand why this ONE feature doesn't get any more attention from the developers: RESTRICT ACCESS to PAGE and only allow viewing for (1) Registerred members or for (2) Specific members.

Come on, this is 2012, it shouldn't come as a shock that this is a necessary feature. I disagree entirely with the answer provided, that one should consider using a CMS or a Forum. A WIKI _SHOULD_ also have this functionality, and in PARTICULAR MediaWiki.

I urge you to consider adding this critical feature. And please don't tell me to go elsewhere, because I won't.

I remind you again that this is 2012 and the MediaWiki project IS mature enough to support this feature now.

Also this has nothing to do with money or making money on MediaWiki, but it is a feature any type of organisation frequently need.

All the best, T

Uh, MediaWiki does have the first, and there are extensions for the second. However MediaWiki's goal was not this. There are other wiki applications with that in mind.--Jasper Deng (talk) 21:14, 26 April 2012 (UTC)

"Consider whether MediaWiki is right for you"

I proposed a certain organization to install MediaWiki. They described their needs to me, so i worked for a few days to demonstrate them that MediaWiki fits their needs - i installed it on my laptop, wrote a few pages in the style they need, defined user permissions to their liking.

But then they asked their sysadmin to install it on their servers. For some reason, he started looking for excuses not to do it. Among other things, he cited this page: "Consider whether MediaWiki is right for you. MediaWiki was not originally designed for private wikis, so other software may be more suitable".

In this case this was already done - as i said, i already demonstrated that the page design and the security is suitable for them. But now this installation is on hold because of this rather ridiculous reason - they are "reconsidering" because this page told them to do so.

Is this sentence still true? Is MediaWiki so badly suited for a "Simple private wiki"? And is this sentence really needed here? --Amir E. Aharoni 15:57, 16 February 2011 (UTC)

They should certainly consider whether this is the software they actually want: most people just install the first thing they see. If MediaWiki really is the best option for them, we may hope their consideration will lead them to that conclusion.

MediaWiki should be able to handle the use case you describe without any problems, although I can recall one hole that was patched only a couple months ago. There's been a certain amount of warning creep over the years (people don't usually like removing warnings!); I've gone ahead and removed this one. —Emufarmers^(T|C) 07:43, 17 February 2011 (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|C) 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|C) 20:21, 6 April 2009 (UTC)

I wanted to prevent anonymous users to read/edit my wiki. i added to my LocalSettings.php those lines and it's still not working. Thanks! --213.203.135.77 08:20, 23 May 2011 (UTC)

# Disable reading by anonymous users
$wgGroupPermissions['*']['read'] = false;
# But allow them to read e.g., these pages:
#$wgWhitelistRead =  array ( "Main Page", "Special:Userlogin", "Help:Contents");
# Like previous, but for French (be careful of encoding! save file as UTF-8!)
# $wgWhitelistRead = array( ":Page Principale", "Special:Userlogin", "Aide en français");
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['sysop']['edit'] = true;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['sysop']['edit'] = false;
# Prevent new user registrations except by sysops
$wgGroupPermissions['*']['createaccount'] = false;
# Prevent new user registrations by anyone
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['sysop']['createaccount'] = false;

The same advice applies as above. Given that you included the same line three times, I suspect you might have added something else you didn't mean to. —Emufarmers^(T|C) 08:59, 23 May 2011 (UTC)

Thanks, i'm not really into those things, i'm sure i messed up somewhere :); if you have time you can see my LocalSettings.php here --213.203.135.77 09:13, 23 May 2011 (UTC)

What exactly isn't working? Are unregistered users still able to see all pages? Can I have a link to your wiki?

You should probably change your database password, since you just posted it for the world to see. —Emufarmers^(T|C) 10:27, 23 May 2011 (UTC)

A way to restrict editing to logged in people, but keep the edit links

I wonder if there is a way to keep the edit links available once I've restricted editing to only logged in users. The use case is this: the people browsing our internal wiki might not realize they can edit unless they see the links. I want to avoid misunderstanding that the wiki doesn't allow edits for them: I imagine they'd more readily click the edit tab then get a login challenge than just guess they have to login to edit the page.

Diff of hack to keep edit links after requiring a login to edit a page

branch

http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_16_5/phase3

Index: includes/SkinTemplate.php
===================================================================
--- includes/SkinTemplate.php	(revision 90117)
+++ includes/SkinTemplate.php	(working copy)
@@ -737,7 +737,8 @@
 			);
 
 			wfProfileIn( __METHOD__ . '-edit' );
-			if ( $this->mTitle->quickUserCan( 'edit' ) && ( $this->mTitle->exists() || $this->mTitle->quickUserCan( 'create' ) ) ) {
+#			if ( $this->mTitle->quickUserCan( 'edit' ) && ( $this->mTitle->exists() || $this->mTitle->quickUserCan( 'create' ) ) ) {
+			if ( true ) {
 				$istalk = $this->mTitle->isTalkPage();
 				$istalkclass = $istalk?' istalk':'';
 				$content_actions['edit'] = array(
Index: languages/messages/MessagesEn.php
===================================================================
--- languages/messages/MessagesEn.php	(revision 90117)
+++ languages/messages/MessagesEn.php	(working copy)
@@ -1008,7 +1008,7 @@
 'actionthrottledtext'  => 'As an anti-spam measure, you are limited from performing this action too many times in a short space of time, and you have exceeded this limit.
 Please try again in a few minutes.',
 'protectedpagetext'    => 'This page has been locked to prevent editing.',
-'viewsourcetext'       => 'You can view and copy the source of this page:',
+'viewsourcetext'       => 'If you haven\'t logged in, try logging in. You can view and copy the source of this page:',
 'protectedinterface'   => 'This page provides interface text for the software, and is locked to prevent abuse.',
 'editinginterface'     => "'''Warning:''' You are editing a page which is used to provide interface text for the software.
 Changes to this page will affect the appearance of the user interface for other users.

Davious 19:21, 5 August 2011 (UTC)

TextEdit for Mac

Is it okay to use TextEdit for Mac computers? It does mention about Notepad for Windows, but nothing for the Mac platform. --TJRana 22:30, 24 December 2011 (UTC)

Notification for closed account

The example

function efLoginFormMessage( &$template ) {

$template->set( 'header', "(For an account to edit articles with, contact Mrs. Nurdsbaum in room B-303, nelda.nurdsbaum@example.com )");

return true;

}

$wgHooks['UserLoginForm'][]='efLoginFormMessage';

seems not to work with MW 1.18. The message doesn't show up at all.

--Francishunger (talk) 20:21, 19 February 2012 (UTC)

I used 1.19 Jidanni (talk) 03:19, 21 February 2012 (UTC)

Broken inter-page link

In section Restrict viewing of certain specific pages the link "see above" (near "configure one as viewable and one as unviewable") seems to be broken, and I am not sure what it should be. What should it be? --Mortense (talk) 09:22, 22 February 2012 (UTC)

Please add more anonymous user examples

Please provide example for ANONYMOUS users to be able to read but not edit article, but allow them to edit talk pages. Sbmeirow (talk) 11:44, 30 April 2012 (UTC)

See Manual:$wgGroupPermissions and Manual:$wgNamespaceProtection.--Jasper Deng (talk) 23:36, 30 April 2012 (UTC)

Prevent unregistered users from viewing files, even if they know the URL

I'm trying to set up a completely private wiki for my nonprofit's internal collaborative use. I've figured out how to prevent unregistered "users" from viewing or editing any pages and how to restrict account creation. But it appears that while the "File:Whatever" pages are protected in this way, the actual files themselves are only secured through obscurity; anyone can view them if they know the URL that leads directly to the file. Is there an extension or other means to block unregistered users from seeing any files, even if they have a direct link? --LouisB3 (talk) 15:03, 9 July 2012 (UTC)

See Manual:Image Authorization, it involves setting up img_auth.php, which is part of core mediawiki. --Skizzerz 06:56, 14 July 2012 (UTC)

Thanks, did this and it worked. -- LouisB3

Preventing creation of certain pages

I was wondering, if there were pages which were being repeatedly created on my wiki, and were recreated every time I deleted them, is it possible to prevent creation of those pages? I don't know if it's a protection function or a preventing access function.

Help:Protecting and unprotecting pages - the procedure described there can also be used to prevent pages from being created. Depending on your skin, entering the page protection menu for a particular non-existing page will, in place of "edit" or "move" restrictions, have a "create" restriction to be set.

Alternatively, you can make use of regex with the use of Extension:Titleblacklist instead, although it typically offers only one protection level.--Jasper Deng (talk) 05:29, 27 November 2012 (UTC)

Clarification on how secure mediawiki is for a totally private wiki

I was wondering if someone a bit more in the know than me could add to this page whether or not mediawiki is reasonably safe/secure (accepting that nothing is totally secure) for a totally private wiki. This page makes it clear that page access restrictions are not secure but I think it would be good to clarify how secure a totally private wiki is?

Totally private wikis (e.g. you do not want logged out users to be able to view anything) are quite secure. You will need to configure img_auth.php to make sure people cannot browse to files you upload, but beyond that simply making it so logged out users are unable to read anything or create accounts should suffice for a totally private wiki. --Skizzerz 02:52, 28 December 2013 (UTC)

Restrict view of Special: from anon

All Im looking to do is prevent anon user from viewing any special page except Search. I NEED to be able to do this without the use of an extension. Im sure the answer is out there Im just not having much luck finding it. Can anyone clue me in or maybe just point me in the right direction?

Thanks all

Not possible without an extension, however Extension:Lockdown will fit the bill nicely. --Skizzerz 02:50, 28 December 2013 (UTC)

Restricting download of part of the files only

The documentation could be improved for this part. Though there is no clean way I know of, it's possible. I saw for instance that http://qed.princeton.edu has one such system, most of the files are open but for some of them (I don't know how many) you're redirected to http://qed.princeton.edu/getfile.php which asks authentication and if you're not authenticated further redirects to [1]. --Nemo 09:52, 15 February 2014 (UTC)

Hi, can you try to find more information, perhaps so that we can cast that into a new extension ? (I did not check, whether there is already one.) --Wikinaut (talk) 10:02, 15 February 2014 (UTC)

The only "working" extensions I know of are Lockdown and SimpleSecurity, they don't handle files. [2] mentions "ImagePathFunctions" which has an associated email address, you could write there. I only found about this while doing something else, no time to really do anything about it. --Nemo 10:12, 15 February 2014 (UTC)

Thx. I think, that a new extension would be very useful which prevents the access to all files based on permissions like we have for "read", "write", or "upload". In correspondence to "upload" (which basically means "can-write-files"), we should have a reliable permission "can-read-files". Can you help to develop such an extension, I am very insterested in having such an extension. --Wikinaut (talk) 10:31, 15 February 2014 (UTC)

Nemo, here's some more: Manual:User_rights#List_of_permissions → entry for "read". There I found information about "Use img_auth.php to restrict image views to only logged-in users.", perhaps this is the wanted solution for my case. --Wikinaut (talk) 11:31, 15 February 2014 (UTC)

Doesn't seem to work on wikia

Wikia says to see this page for instructions to do this. I put $wgGroupPermissions['*']['edit'] = false; in my Manual:LocalSettings.php but IP addresses can still edit. Is the information on the page up to date? Dream Focus (talk) 18:15, 10 August 2015 (UTC)

This page is still up to date and accurate. On wikia you can't edit LocalSettings.php, so I'm wondering what LocalSettings.php are you editing --Ciencia Al Poder (talk) 09:26, 11 August 2015 (UTC)

Anyone can edit /wiki/Manual:LocalSettings.php on any wikia they are the administrator of. Dream Focus (talk) 10:55, 11 August 2015 (UTC)

Sure, but that will be a page called Manual:LocalSettings.php on the wiki, not a file called LocalSettings.php located in the server! That file contains important information like passwords that shouldn't be publicly accessible. --Ciencia Al Poder (talk) 17:18, 11 August 2015 (UTC)

They announced they recently had a hack done on some wikias that stole passwords. Maybe when they fixed it, they stopped this from working, because Wikia staff members previously linked to these instructions on how to block IPs from editing on a wikia. Does anyone know a way to make this work? Dream Focus (talk) 18:32, 11 August 2015 (UTC)

"To have a Whitespace or not to have a whitespace, that is the question here"

@Mlpearc, Pokéfan95, 83.220.238.225, and 188.32.102.177188.32.110.75: Ok, after several edits of adding and removing whitespaces inside [] I now force you all to discuss this before taking any further action ;) The page is restricted to be edited by admins only for 1 day. I suggest, that all of you discuss the pros and cons first and then edit the page again with a discussed proposal with which all can live. Thanks! --Florianschmidtwelzow (talk) 17:37, 24 May 2016 (UTC)

Hello, I reverted those IPs because they are cross-wiki vandals. See m:Steward requests/Global#Global block for 188.32.96.0/19. Those IPs are operated by a LTA. Thanks, Pokéfan95 (talk) 01:44, 25 May 2016 (UTC)

How to have an expiration date for my users ?

Hello, I am trying to make something simple, but I can't find a way.

I want to set an expiration date for my users, which prevent them from using the wiki if the previously set date is met. Is it possible to do it simply ?

Thanks in advance.

Loginstart / Loginend

Under Manual:Preventing_access#Restrict_account_creation the two interface messages Loginstart and Loginend are mentioned. Are these still in use or are they both depricated in favour of Loginprompt? /André Costa (WMSE) (talk) 10:59, 24 January 2018 (UTC)

Prevent special pages / language

I would want to prevent anyone besides sysop to access the special pages. So i tried something like this:

# Lockdown start 
wfLoadExtension( 'Lockdown' ); 
$wgNamespacePermissionLockdown[NS_SPECIAL]['read'] = array('sysop') 

or ... in case I missed the "direction" of the permission... (naturally I will extend this to 'edit' etc. when I get this working.)

# Lockdown start 
wfLoadExtension( 'Lockdown' ); 
$wgNamespacePermissionLockdown[NS_SPECIAL]['read'] = array('user') 

In both cases I can not access the site! What am I doing wrong? Further I tried to do all variations over these - still no luck:

$wgSpecialPageLockdown['*'] = [ 'user' ];
$wgSpecialPageLockdown['SpecialPages'] = [ 'user' ]; 

And an extra question - I installed this in a different language. Do I need to figure out the English title/terms for the pages etc. or do the extensions have some way of translating the parameters? --— Preceding unsigned comment added by AssetDenmark (talk • contribs)

The login page is a special page. If you don't whitelist the login page, you're effectively locked down from logging in!. You may have better luck asking for help on the extension talk page. --Ciencia Al Poder (talk) 09:32, 8 April 2019 (UTC)

@AssetDenmark: Yeah, or you may just ask on Project:Support_desk so that more people can see it. --94rain (talk) 14:17, 8 April 2019 (UTC)

thanks i tried to put this on under the Extension_talk:Lockdown page, I also tried to zap out all other localsettings...AssetDenmark (talk) 08:17, 9 April 2019 (UTC) (thanks @94rain: and @Ciencia Al Poder:

Why would we want to allow access to Special:RunJobs?

Brett LaRue (talk) 15:50, 17 March 2020 (UTC)

That special page is called internally by the Manual:Job queue if $wgRunJobsAsync is set to true and $wgJobRunRate is greater than 0. Otherwise it's safe to deny access to it --Ciencia Al Poder (talk) 15:23, 19 March 2020 (UTC)