incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <dbronds...@slashdotmedia.com>
Subject Re: Anti-Spam form-field renaming (without EasyWidgets?)
Date Wed, 17 Jul 2013 15:39:20 GMT
On Wed, Jul 17, 2013 at 11:20 AM, Cory Johns <cjohns@slashdotmedia.com>wrote:

> On Tue, Jul 16, 2013 at 4:19 PM, Dave Brondsema <
> dbrondsema@slashdotmedia.com> wrote:
>
> >
> > 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.
>
>
>

 I misremembered.  I was thinking of the disable_csrf_protection flag,
which unrelated


-- 
Dave Brondsema
Principal Software Engineer - sourceforge.net
Dice Holdings, Inc.

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