http://www.koha.org/wiki/ is being attacked by linkspammers almost every day. Recently, they have become more destructive, wiping out acres of material, such as on the QuestionsPosed page. I'm against forcing user registration, but can we take some other action against these? Maybe some simple way to mark a change as spam, revert to the previous and flag it for the admin to look at (to ban IPs, contact remote network admins or whatever). It's not as easy to deal with total destruction of pages, unlike the simple "add links to end of page" spam we used to get. -- MJR/slef My Opinion Only and not of any group I know Creative copyleft computing - http://www.ttllp.co.uk/ Unsolicited attachments to the pipex address deleted Will HLF fund tree-killings? http://www.thewalks.co.uk/
MJ Ray wrote:
http://www.koha.org/wiki/ is being attacked by linkspammers almost every day. Recently, they have become more destructive, wiping out acres of material, such as on the QuestionsPosed page.
I'm against forcing user registration, but can we take some other action against these? Maybe some simple way to mark a change as spam, revert to the previous and flag it for the admin to look at (to ban IPs, contact remote network admins or whatever). It's not as easy to deal with total destruction of pages, unlike the simple "add links to end of page" spam we used to get.
That's a real shame - hmm, is there a way that unregisterd users changes get sent for vetting? so you have to register to edit directly? Cheers Rachel -- _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications MANAGING DIRECTOR Ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org
Rachel Hamilton-Williams wrote:
MJ Ray wrote:
http://www.koha.org/wiki/ is being attacked by linkspammers almost every day. Recently, they have become more destructive, wiping out acres of material, such as on the QuestionsPosed page.
I'm against forcing user registration, but can we take some other action against these? Maybe some simple way to mark a change as spam, revert to the previous and flag it for the admin to look at (to ban IPs, contact remote network admins or whatever).
The current wiki software ( http://tavi.sourceforge.net/ ) does not offer much in the way of protection against spammers: Currently a page is either open for editing or locked and there is only provision for a single 'admin' password. There has been on-going discussion of alternative options here: http://tavi.sourceforge.net/TaviLoginIdeas The main sourceforge site along with thousands of other wikis have become increasingly subject to spam attacks over the last twelve months. The tavi wiki software has not kept pace with these developments and has seen little development in general over the last two years.
It's not as easy to deal with total destruction of pages, unlike the simple "add links to end of page" spam we used to get.
The wiki is backed up nightly (sqldump - around 16:00 GMT) and there are monthly backups (held for at least six months), but there is no simple way to restore a previous version of a defaced page via the in-built revision control system. Taking all of the above (and related issues such as RSS problems) into consideration, it may be time to look for an alternative solution? Any comments/suggestions? R.
On 2004-11-04 08:04:52 +0000 Roger BUCK <rog@saas.nsw.edu.au> wrote:
The tavi wiki software has not kept pace with these developments and has seen little development in general over the last two years.
How much development does a wiki need? They should be fairly simple tools that do a fairly simple task well. I recently ranted about creeping featurism in Kwiki on http://mjr.towers.org.uk/blog/2004-8.html#kwiki1101
The wiki is backed up nightly (sqldump - around 16:00 GMT) and there are monthly backups (held for at least six months), but there is no simple way to restore a previous version of a defaced page via the in-built revision control system.
That's a shame. Is there a complicated way and is it possible to automate it? Even just a "this page has been spammed" link to tell someone who can roll it back would help. One wiki I use has a single username and password (htaccess) which seems to stop nearly all spammers, despite the login prompt (AuthName) saying what the username and password are!
Taking all of the above (and related issues such as RSS problems) into consideration, it may be time to look for an alternative solution?
Possibly. Recently, I have used: * MoinMoin - never liked this one or used it much * Twiki - only as a user - seems very complicated with multiple webs and user registration - supplied templates are buggy * Kwiki - 0.18 is fast, easy to install and flexible, but the current 0.33 has several obscure dependencies and doesn't seem as simple to modify - supplied templates are buggy in both versions - revision control extensions available * UseMod - fairly easy to install, but is one huge perl script so probably not easy to modify. Revision control included. * PhpWiki - stable version is fairly easy to install and use - similar to Tavi, I think. Newer version has lots of plugins and extensions. WikiMarkup is quite different to the normal one, I think. I may have confused some of those. You are in a maze of twisty WikiCode, all different. -- MJR/slef My Opinion Only and not of any group I know Creative copyleft computing - http://www.ttllp.co.uk/ Unsolicited attachments to the pipex address deleted Will HLF fund tree-killings? http://www.thewalks.co.uk/
MJ Ray wrote: [--snip--]
One wiki I use has a single username and password (htaccess) which seems to stop nearly all spammers, despite the login prompt (AuthName) saying what the username and password are! [--snip--]
As a temporary measure, and depending on feedback, the above suggestion has been implemented (username=koha password=kohatoo). Apologies for the lack of consultation but some triage was required to inhibit what has become daily spam attack. Thanks to MJR for suggestions in previous message (not ignored - just not quoted :) R.
participants (3)
-
MJ Ray -
Rachel Hamilton-Williams -
Roger BUCK