-----Original Message----- From: openguides-dev-bounces@openguides.org [mailto:openguides-dev-bounces@openguides.org]On Behalf Of Kake L Pugh Sent: 24 August 2004 12:46 To: openguides-dev@openguides.org Subject: [OpenGuides-Dev] Combatting wiki spam

I think pretty much every OpenGuide has been hit by the casino spammers - basically they edit Wiki Etiquette and Wiki Info to include their URL as many times as possible, trying to capitalise on our googlejuice.

We implemented admin delete to deal with this, but it does seem to be the same spam over and over again, so guide admins are having to delete it over and over again. Luckily we have a tool to deal with automating repetitive tasks.

I would like this to be optional, extensible and configurable. Here is a suggested spam filtering config file (see Config::Tiny for syntax).

---

[discard_edit] locale = www.casino-online-online.com category = www.casino-online-online.com

[discard_edit_regex] locale = www..* category = www..*

[notify_edit] notify_to_email = kake@earth.li username = Anonymous

---

I agree that we need discard_edit(_regex)? immediately. We need a way of blocking a range of IP addresses and/or domains.

(I don't plan to implement notify_edit yet, just stuck it in there to show that this form of config file is quite extensible. Dare I say it, this might be a good task to be implemented as a plugin.)

I am thinking that this is the beginnings of a user permissions plugin. But I don't think that we need full blown user permissions to start with.

Also, I think that some admins might prefer the 'notification' to be held on the wiki rather than sent via email. They would receive the actual notification via RSS syndication.

When someone/thing tries to commit an edit that matches a discard rule, they'll get an error message explaining what they did that was naughty. So you could use this to block anonymous edits too, by adding the line "username = Anonymous" to the discard_edit section.

You might want to put some kind of permissions scheme on the pages. A page could be locked - read only to all but admins. Or it could allow an edit, but save the changed version in a different part of the database until someone approves (or rejects) it.

Comments? Is there a better way to structure the file without having to add any more prereqs? (I was thinking YAML, but that's yet another prereq and people already complain about how many there are, plus it's another syntax for people to learn.)

In particular, this syntax doesn't let us say things like 'Disallow edits if EITHER the locale is "foo" OR (the locale is "Hammersmith" AND the username is "Anonymous")'. I *don't* plan to implement anything that complex right now, because it's not *needed*, but I don't want to tie myself into a format that precludes doing it later.

How about basing it on the apache httpd.conf with a few minor variations. This is at least a format that people are used to.

My twopenn'orth,

Ivor.