Hmmmmmmm... Couple of observations: - I understand your point about needing *two* random field names (shorthand: one filled, one not). Easily done, if we do a custom tag. - My suggestion on wiki:spamProtect was meant to indicate the goal of the tag, not necessarily the class that relies on the outputit creates (SpamFilter). We could certainly call it wiki:SpamFilterFields, but that seems a little clinical. Not passionate about this; just thought it might be better to express the intent of the tag, not the machinery behind it. - Randomizing "all" field names kills Stripes parameter binding dead. So that is not a good idea. - My suggestion of checking for the @TicketRequired annotation before doing the SpamFilter checks was mostly about re-using an annotation to keep things simple, but we need not do that. I should have probably explained the "buried premise" behind that. The premise is that what we do for spam detection should probably work on more than just the Edit & Comment JSPs. There's other places we need to do it, like user registration, group creation, etc. So my comments were oriented towards strategies for making spam protection generally reusable wherever we needed it. That might not have been clear, but it's what I meant.
The strategy I'd used with the anti-CSRF feature for Stripes was to have the thing that creates the ticket parameter (during the GET) collaborate with an annotation signifies something important to the controller (during the POST). That is, the tag tells us to generate the special fields, and the annotation tells somebody (later) that we need to look for them. The "somebody" is an Interceptor, which means we can re-use that function across the entire webapp. That's the kind of strategy that could work for SpamFilter, too. The bottom line is that it's damned simple: add an annotation to the method you want to protect, then add a matching tag to the JSP that creates the form. Everything else is hidden away. For the annotation, we can use our own, like @SpamProtect.... or @SpamFilter :) Of course, all of the foregoing is *before* we get to actual content analysis, which is now, and will continue to be, done in the SpamFilter. On Tue, Mar 10, 2009 at 6:18 AM, Janne Jalkanen <[email protected]> wrote: >> The SpamFilter does not stash anything in the Session (because spambots >> sometimes do not send cookies). > > D'oh, shouldn't have written this before breakfast. Of course we write > the hashfield name in the Session. > > But my comment still stands not wanting to do this in a > Stripes-dependent manner. I especially don't want us rejecting edits > in multiple places. > > Besides, I want to enhance SpamFilter to go into a direction of > SpamAssassin, that is, allow different weights for different tests. > This means that SpamFilter must get all the relevant data and be able > to reject/approve things without the framework getting in the way. > > /Janne >
