incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <>
Subject Re: Anti-Spam form-field renaming (without EasyWidgets?)
Date Tue, 16 Jul 2013 20:19:20 GMT
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).

On Tue, Jul 16, 2013 at 1:00 PM, Cory Johns <>wrote:

> I know Allura has an anti-spam middleware in place that renames form fields
> automagically to non-human readable, but I have a couple of questions
> regarding how it works.
> Firstly, I'm adding a new form and eschewing EasyWidgets for various
> reasons.  I noticed that the form fields were not getting renamed, so I'm
> wondering if there's something I need to do to avail my form of the
> anti-spam magic, or if it's something that's tied to EW?

In, 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/ hooks into that.  Thus everything
that inherits from ForgeForm (most if not all of our forms, I'd think) get
that functionality.

> Secondly, I noticed that the field ID values aren't changed, which makes
> sense as it would make writing javascript difficult, but I wonder how much
> renaming the field names but not the IDs actually is.  I guess point is to
> block bots that just replay the form submission, but is it really that much
> of an obstacle to request the form and extract the field names by ID first?
>  Is this a case of "any hurdle we can throw up helps, no matter how small?"
>  Is it perhaps a hold-over of earlier attempts at spam prevention and is
> maybe less relevant now?
> 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.

> 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.

> Should I just not worry about ensuring that the field renaming magic works
> on my new form?

If we want to prevent spam bots from abusing that form, we should use the
g.antispam mechanisms.  More broadly, if we're starting to implement some
forms not using EW (I know there is some general dislike for EW, so seems
like a reasonable thing to start doing), then it'd be good to we want to
establish some patterns for doing that, including making it easy to use the
antispam functionality.

Dave Brondsema
Principal Software Engineer -
Dice Holdings, Inc.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message