optional "timeout" parameter). FYI the ticket parameter name is not actually randomized; it's overkill because the value isn't predictable. The patch is here:
It's not overkill. Trust me. You will want to have two parameters with random names that need to be treated differently at the server end (one is full and one is empty).
This is to curb those bots which understand the post schema used - you want to write it in such a way that any "post this field to that" - schema does not work.
I've been thinking about randomizing all input field names just to make things more complicated.
As for the other items (#1 and #3), these are things I'd like to reimplement, but in a slightly different way. I agree that a tag would be good, although I prefer "wiki:spamProtect." Similar to how we do it
I would prefer to attach it to the SpamFilter name (wiki:SpamFilterTags) because then it's obvious who uses them.
Where I think we could do things a little differently is how we manage stuff that gets stashed in the session.
The SpamFilter does not stash anything in the Session (because spambots sometimes do not send cookies).
We could re-use the Ticket scheme I developed for Stripes, or do something like what Stripes does, which is to write out an encrypted parameter with the name of the spam-trap param as the payload. The latter is probably the better approach. Verification would be via an Interceptor, and we could simply state that if the target ActionBean event handler method had a @TicketRequired annotation, we should *always* do the spam-check thing.
No, we should leave this configurable to the enduser via our filtering mechanism (which works regardless of whether Stripes are used or not, e.g. for embedders). I see no reason to involve Stripes here.
People who are embedding JSPWiki as a part of their own webapp will probably also need a spam filter.
/Janne
