Table Of Contents


This page is here to provide further background into our wiki farm setup, hopefully it will answer such questions as why cant we block WikiSpammerXy from all the wikis at the same time and how can we better protect our wiki, what is in place and how can we better it, etc..

A bit of general wiki setup background

The ASF MoinMoin wiki farm consists of many separate project wikis - all derived from a base config but at the same time, all are independant of each other and each can override some of the base config options (some useful and in use, others not so.)


Currently, each project wiki in the wiki farm has its own set of registered users (apart from newly created wikis as of 2011) and so if anyone is a registered user of one project wiki such as say Incubator wiki, they are NOT also a registered user of any other wiki unless they register for that one too. This is obviously not ideal for users that belong to several projects and so this is being addressed and will be phased out in the future in favour of a shared wiki user base. (This is not a quite straight forward merger of accounts, ACLs such as those in AdminGroups for one wiki may not neccessarly need to be so in another wiki etc.). It is aimed for the end of 2011 for all user accounts to be migrated to a shared user base.

Spam Prevention Measures

Here are a few implementations on our wiki farm :


textchas (text versions of captchas, more accessible etc etc..) are implemented on a ASF farm-wide basis. textchas affect a few areas of the wikis:

all of which are good in the fight against automated spam. None of which are a deterant against the manual spammer of which we have had a few on occasion - see the next section below however on how changing your wiki ACLs slightly can help dramatically against the manual spammer.

Ok, back to textchas; Currently, textchas are easy questions that have easy answers, randomly chosen from a preset selection created by us. if desired, these questions can be overridden on a per wiki basis should a project want to do that. In addition, if you have ACLs (Access Control Lists) defined for your project wiki, it is also possible to turn off textchas for certain groups. For instance, currently enabled, any person part of an AdminGroup defined for any wiki in the whole farm, congrats! you do not need to answer any textcha questions when editing pages of that wiki (or wikis) whilst almost everyone else does. On a per project wiki basis, one can also add a secondary group to not require textchas, that of a more trusted group that are not actual admins, but editors. More in the next section.

textchas are a basic form of spam prevention as mentioned, mainly to prevent the automated spammers. It has been asked for that this type of prevention be added back in to our farm and so that has been done. You may be a part of one those rare wiki projects that does not in fact want textchas enabled, nor any other kind of ACL/textcha combo. That being the case, contact infra who can on a per wiki basis, turn off textchas (and let you get on with your own spam removal methods as the spam instances start to rise again, dont say you weren't warned.!)

per wiki access control - tighten your wiki just a little, benefit just a lot

Long sub-title for a fairly long subject.

The MoinMoin wiki is very configurable, more so than some might think. Of course, wikis are meant to be open, for complete and utter open collaboration. That is appreciated. However, there are some that would like a balance between open wiki and having to spend time cleaning up spam each week. Times change, and the reality is, spammers are here and in greater numbers than before. What can we do? Well, here is a suggestion - and one that can be easily implemented and takes but 2 minutes (for infra) to set up.

Have your project wiki editable only by a custom trusted group - that need not be committers only - it can in fact still be anybody who wants to edit your wiki, they just need to ask one time for edit access and thats it. Is this an incovenience? To ask once for access, I don't think so. After all as a potential contributor to your wiki you (project) will already be conversing with the potential contributor via the mailing lists right? How much pain is it to add someone to the custom trusted group once it has been set up? , no pain at all, a member of the projects AdminGroup edits one wiki page, adds the users WikiuserName to the bottom of the list and save the page! 10 seconds maybe and your done. For the amount of times you will have to do that as opposed to the amount of times you spend cleaning up spam - you work out which is better.

The spamassassin wiki is a good example - those in the project wikis AdminGroup can add folks to the projects ContributorsGroup and that's it. How much spam has spamassassin received since this was setup ? Zero, Zilch, Nil, Nada.

Remember also, any page can have its own access control which overrides and per wiki and per farm defaults - This page does just that, as does LocalBadContent and BadContent pages.

BadContent and LocalBadContent pages, how do they work?


The BadContent page is updated from the Master BadContent page at whenever an edit is made to the local wiki. The local BadContent pages from each wiki not writable. Do not use any admin privs to try and edit it as edits will be overwritten.

Also seriously consider updating the master moin BadContent page directly - as soon as you edit that page, it will be available to all wikis. This is a MUCH better system to protect our whole wiki farm rather than editting only the LocalBadContent pages, which apply only to that wiki. [Note: many LocalBadContent pages have comments that imply they are automatically copied from the general wiki; however that is no longer the case - see below.]


LocalBadContent pages are designed to be editible immediate fixes on a per wiki basis. Updated manually by AdminGroup members and should only be accessible by AdminGroup members. The page works in conjunction with BadContent, but should not be regarded as the permanant fix, instead, use it, then add the same information to the Master MoinMoin/BadContent page which anyone can edit. In previous editions of 'our' (ASFs) moin wiki, we used this 'general wiki' LocalBadContent page and this propogated down to all the other wikis - this NO LONGER happens nor will we be bringing this feature back, it is better for all to simply edit the master moin BadContent page instead -- same amount of work, benefits all!


Look after your own LocalBadContent page, ensure it is restricted to AdminGroup only. Restrict your own wikis BadContent page to AdminGroup only and leave it alone. Anything you add to your LocalBadContent page, add it also to the main master wiki BadContent page at - this will ensure it then filters back down through the chain and into all of our wikis BadContent pages.

Handy config information about our wiki

This section is useful for anyone with access to our wiki config files, but also may serve as working examples I guess for others browsing.

Enabling textchas

Included in our ( for non-farms) :

textchas_disabled_group = u"AdminGroup" # members of this don't get textchas
textchas = {
            'en': {
                   u"Is the ASF a 501(c)3 public charity?": ur"yes",
                   u"ApacheCon NA 2010 was hosted in which city?": ur"Atlanta",
                   u"Which of these is an ASF project: Teepee or Lucene?": ur"Lucene",
                   u"A chicken has how many legs?": ur"two|2",
                   u"Subtract five from eight?": ur"three|3",
                   .. (etc..)

Now, the above snippet can also be added to each wiki $ file and theefore override the above with your own set of questions and your own excluded list for textcha folks. (Such as another TrustedGroup)


Note that due to spammers, attachments are also disabled for the whole wiki farm. Every time we have lifted the ban, it starts again. So this is now a permanant feature for the foreseeable future. However, should you choose to apply a slightly more restrictive ACL scheme as shown below by applying a ContributorsGroup, then we can and will re-enable attachments on a per wiki basis as the attachments are also then protected by the ACL in use.

Enabling per wiki override of ACLs

Some of our wikis use a finer grade of Access Control to prevent Spam but still make it easy to contribute, here are the basic additions needed. Just add these lines to the $ file to override the main config:

    acl_rights_default = u"ContributorsGroup:read,write,delete,revert All:read"
    acl_rights_before  = u"AdminGroup:admin,read,write,delete,revert" 

Simple as that, along with a page in the wiki containing AdminGroup list of folks, and a page called ContributorsGroup containing a list of folks and it's a done deal. Anyone new wants to edit your wiki, add them to the ContributorsGroup page.

Note: members of the AdminGroup can edit pages; they don't have to be added to the ContributorsGroup as well.

However, the AdminGroup itself must be added to the ContributorsGroup otherwise members of that group will be asked to complete a Textcha. It can be added as a simple name:

 * AdminGroup

Or it can be added as part of some explanatory text, for example:

Related: [[AdminGroup| Administrators]] with permission to grant privileges to Contributors, in addition to being Contributors themselves.  NOTE: This list is not publicly viewable.

The ContributorsGroup page should have the following ACL to ensure it can only be updated by the AdminGroup

#acl AdminGroup:read,write,admin,revert,delete All:read

The AdminGroup page should have the following ACL:

#acl AdminGroup:read,write,delete,revert,admin -All:read

wiki spammer tactic example and another config choice

Wiki spammers have been seen to impersonate another more accepted regular account by creating another account that looks very similar. This, I guess, is to give the false impression that a change to a wiki page was done by someone with authority to do so, making it seem a more valid change than it is - also presumably meaning that those reviewing diff changes via wikidiff emails wont even bother to review due to the name associated with the change.

Example - you have an Admin in your wiki called JohnDoe who is respected for his wiki edits. Spammer comes along and creates an account of name JonnDoe or JohhDoe or JahnDoe etc etc... , it could be easily missed. This tactic has been used very recently on a number of wikis.

Keep the above in mind, be vigilant. Also, as a precaution, I suggest limited viewing of your AdminGroup list of people to only the AdminGroup itself. Do this by editing the AdminGroup page and replace All:read with -All:read , leaving in place the AdminGroup perms of course as is.

Who can edit this page: AdminGroup

OurWikiFarm (last edited 2013-03-22 14:08:48 by SebastianBazley)