Manual talk:Preventing access/Archive 2

Jump to navigation Jump to search

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? -- 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#Restrict viewing of all pages:

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? -- 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. 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 -- 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. 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 Tournesol.pngMediaWiki 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#Restrict_editing_of_an_entire_namespace -- 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 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. --Skizzerz 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. --Skizzerz 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? -- 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? -- 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). --Skizzerz 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? :-) -- 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 ($wgGroupPermissions['editor']['edit'] = true; 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.) -- 16:01, 12 November 2008 (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? -- 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:


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. 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? -- 17:26, 4 December 2010 (UTC)[]