On Tue, Jul 16, 2013 at 4:19 PM, Dave Brondsema <
[email protected]> wrote:
> In app_globals.py, g.antispam is set up as the main class that does the
> work. And it looks like the ForgeForm EW class
> in Allura/allura/lib/widgets/forms.py hooks into that. Thus everything
> that inherits from ForgeForm (most if not all of our forms, I'd think) get
> that functionality.
>
g.antispam looks easy enough to use; just use
"{{g.antispam.enc('field_name')}}" instead of "field_name" in your
templates and iterate over g.antispam.extra_fields() for the honeypot
fields, then add @allura.lib.utils.AntiSpam.validate('Spam protection') to
your post handler. This is exactly what I was looking for, thanks.
>
> > Actually, I noticed that changing the field name to the original,
> > un-magicked, field name via the debugger and then submitting the form
> > actually works fine. Since Allura is open-source, the original field
> names
> > are easy to discover and it seems that the field renaming is entirely
> moot.
> >
>
> That does seem like an issue and something we should fix. Perhaps it's
> because there's an option to turn off this antispam field renaming, so the
> controllers handle it either way. But would be better to not allow the
> original names if antispam is on for the form.
>
I think this is just because allura.lib.utils.AntiSpam.validate() adds the
un-obfuscated fields to the params but doesn't remove them if they're
already there and the obfuscated fields are not present. Should be an easy
fix, but will require quite a bit of testing to make sure we're not
inadvertently relying on this somewhere.
Also, what do you mean about the option to turn off the field renaming? I
don't see anything about that in the AntiSpam class.
Now, I'd like to preface the rest of my reply by making it clear that I'm
not actually advocating discontinuing the use of allura.lib.utils.AntiSpam.
It does get the low-hanging fruit, with regards to spam bots, and it's
easy enough to use that I do think it's worth it. You answered my real
question above, the rest of this is just me ruminating on its actual
effectiveness in practice.
Note everywhere I say "antispam" I mean the anti-bot mechanisms and is
> unrelated to the spam filtering plugin support for Akismet, etc that we
> also have in Allura (which is hooked up to just a few forms).
>
Of course, Akismet (or any content-based filtering) will only work on
content-based forms, such as discussion posts, tickets, wiki pages, etc.
Places like the add_project form will never benefit from Akismet
filtering, unfortunately.
http://nedbatchelder.com/text/stopbots.html is the basis for our
> implementation. A spam script that was aware of all our prevention
> mechanisms certainly could account for them and succeed. But there are
> lots of bots that are simplistic, so these barriers block them, and it's
> worth it.
>
There are a couple of issues with that, however.
First, that post is over 6 years old at this point. Even generic spam bots
have had a lot of time to improve, and something like basing the field
value on the label element's text (which is clearly and consistently tied
to the field, as it should be for accessibility) is not a difficult
innovation, and is one that would be useful on many sites. The bots still
have to fetch the form once per post to get the spinner field, but the
consistent ID and coupled label render the honeypot and field name
obfuscation significantly less effective.
Second, that post is clearly addressing the problem of un-targeted spam, as
evinced by the quote, "Spammers don't make software that can post to any
form, they make software that can post to many forms." But with the Allura
platform being open source and SourceForge being a well-known site that
uses it, it unfortunately doesn't really fall into the "un-targeted'
category. While it might not be worth a spammers while to put specific
effort in to spam Ned's site(s), it certainly seems like it would be to
target sites powered by Allura.
