Manual talk:Preventing access

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)

Restrict access to paid users
Is there any easy way to restrict access to paid/subscribed users (with some sort of PayPal integration) to all pages by default, but certain pages are selected as being viewable by everyone? --69.165.157.226 17:37, 4 June 2009 (UTC)

Why does .htaccess not work in MediaWiki
I'm baffled by this: If I try to password-protect the folder where MediaWiki is installed with .htaccess (through C-Panel) I get a Document not Found error message (404). All I want is for users to have to use a password to gain access to the main page.

Is this not possible for some reason?
 * .htaccess is a web server feature unrelated to MediaWiki. Refer to Apache docs and your hoster's support. Max Semenik 19:24, 22 November 2009 (UTC)

"Restrict" is different from "prevent"
In the section Restrict editing of all pages, the subheads are
 * 1) Restrict anonymous editing
 * 2) Restrict editing by all non-sysop users
 * 3) Restrict editing by absolutely everyone

These sections describe how to prevent anonymous editing (etc.) completely, not restrict it (e.g., to users from a particular IP). Managing a wiki is complex and daunting enough already; at least the documentation should clarify, not confuse! I've changed
 * Some examples:

to
 * Some examples of how to protect all pages from editing (not reading) by certain classes of users:

-- Thnidu 23:25, 4 February 2010 (UTC)

Moving pages
Was fairly surprised to see that there's no information here on restricting the ability to move pages. 92.29.104.53 17:14, 3 May 2010 (UTC)

Restricting page creation inside a specific namespace...
...while not restricting page creation in other namespaces, and not restricting edits to existing pages anywhere. Is this possible? --Zas 12:41, 7 September 2010 (UTC)

Hide the log IP address to anonymous visitors
I would like to hide or mask the log IP addresses from being viewed for anonymous visitors. As a concept it is very easy, when an user (except from sysops) load a page with the IP addresses, those are being replaced by a "word" (anonyomous). The problem I do not know how to implement it.

The purpouse is to identify vandalism easily permitting to use the checkuser, then only sysops would be capable to see the log IP addresses on recent changes or view history, I think it is not necessary to share this privacy info to any person who visit my wiki. A lot of countries are increasing the privacy laws and it is an important thing to do. And of course I do not want to disable the IP log using $wgPutIPinRC.

Maybe a simple div to show/hide the content would be an "easy" solution.

Any idea?

--Neoshinji 09:28, 5 October 2010 (UTC)

restriction by pagename extension
As far as I'm aware, .css and .js pages in User: space are restricted from editing by other users without sysop privileges for security reasons. Where is this done, and is it possible to add other extensions to this list? --80.228.209.119 17:26, 4 December 2010 (UTC)

How diffs could be visible again in the RSS or Atom feeds ?
In Manual:Preventing access 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)

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 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 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"
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 07:43, 17 February 2011 (UTC)