I also think it is too dangerous to offer spammers a dummy jspwiki.org, chances are that goodwilling editors are loosing their edits in the dummy wiki. Another more rigorous approach would be to only allow authenticated users to edit and comment (so anonymous or asserted users can no longer edit/comment), and expand the user registration process with an email confirmation step.
But looking at the amount of spam-edits done so far, this might give a little bit too much collateral damage. (I also had a quick look at the registered users, and it seems to me that there are quite a few with invalid email adressess, I think those should be removed, what might also be a good idea is an extra attribute that holds the last access date of the user, this allows for removing users that haven't been used for a long time). regards, Harry 2007/12/26, Janne Jalkanen <[EMAIL PROTECTED]>: > > > not sure if it possible, but why not let him have hi userid and > > when he logs in > > with it, send him to a clone of jspwiki.org, or code up a 200 > > response jst for > > him but throw away his edits ? > > > > > > I know this is outside normal wiki framework, but might allow the > > wiki to > > continue ? > > May be possible, but that would need a sure-fire way of recognizing > the userid. And, if we can do that, we could probably stop the edits > right away. > > I've been toying with the idea of collecting the IP addresses he > comes from, and building a "permanent blocklist". Also, it might be > cool to have a four-layer option set for edit management: > > 1) approve > 2) send suspect edit to a captcha routine > 3) send suspect edit to a human to approve > 4) reject outright > > Currently our system is not that fine-grained. > > /Janne > -- met vriendelijke groet, Harry Metske Telnr. +31-548-512395 Mobile +31-6-51898081
