Symphony.

Hi Stuart. I am not using JS validation.

What I meant was that it seems as if the spammers bypass the Can of Spam validation (happens in Symphony Event logic, not JS). If this is the case I find it worrying.

Besides from this potentially worrying (security?) issue (but it might be something else) there's the practical issue of me getting too much spam. This is why I'll add a simple (non-JS) honeypot approach and see how that works.

Updated for Symphony 2.3 and completely rewritten to address some issues mentioned here.

Pull request pending...

Pull request merged by Nick.

Nice work there Jens!

Thanks @jensscherbl

I do not yet have a 2.3 install to test this out, but did you by any chance happen to look into the issue I mentioned earlier in this thread? It seems the required fields etc. are bypassed.

Also, I was recently thinking about an additional blacklist feature. It's far from fail-safe but I guess having an additional (custom) blacklist feature (blocking on some commonly used, irrelevant, nasty words) would be another barrier.

This does not seem to be much work: adding a new check that runs the content through a blacklist. Idea?

@davidhund Sometime ago there was an extension around specifically for that. It's called Indecent Filter but hasn't been updated (yet?) to 2.3.

@alpacaa thanks. That seems to do what I want. I was just thinking about it being built into Can Of Spam.

davidhund Not yet, sorry. To be honest, I don't even know where to start looking regarding your specific issue.

Not sure if it's really a good idea to add a blacklist feature directly into Can Of Spam. I'd rather update the extension alpacaaa mentioned and make sure both extensions work well together.

Sure, I can see where you're coming from.

The only thing is that I think CoS has been adding spam-blocking features for some time so why not add another. Still: if the two extensions work well together that would be cool too.

The only thing is that I think CoS has been adding spam-blocking features for some time so why not add another.

Not sure what you mean. CoS does only and exactly one thing: Generating and checking a unique hash. Nothing more.

Even the XSS filter is a separate extension, so I think keeping those two spam protection functionalities (hash validation and blacklist) separate is more in line with Symphony's general philosophy (but maybe this isn't the best example since I think specifically the XSS filter should be in the core instead).

Keep it separate, it's different functionality.

@jensscherbl Sorry, I don't know what I was thinking :) I was convinced that @designermonkey had added a few other spam-blocking measures (such as IP blocking and a honeypot) to the extension.

However, I could not find any evidence of this so apparently John has been really busy in.my.head :/

Anyhoo: I agree, better to keep the different functionality separate. It's more Symphony-like.

I have the Stop Forum Spam extension, which @vladg added loads of stuff to, are you thinking of that?

which @vladg added loads of stuff to

Uhm, not me :) maybe someone else.

I do that a lot.

@designermonkey Yup, that's the one. I got them mixed up in my head.

Wouldn't it be wise then to break up the "Stop Forum Spam"-extension as well to follow the same principles (every extension does only one thing)?

And we should rename the extensions to make more clear what they do:

• Spam Protection: Hash Validation
• Spam Protection: Blacklist
• Spam Protection: Honeypot
• etc.

Also, every extension developer should make sure there are no conflicts when combining different methods of spam protection.

That way we could make the ecosystem more consistent, prevent duplicated functionality across extensions and it would be easier for beginners to find and use the right extensions for their use cases.

I initially wasn't going to pull in the changes that were made, as I agreed with what you just said. It does make sense to me to be honest. I can quite happily roll them back.

Re naming: Sounds like a plan. Any that are on Symphonists are a go for this, just let either Nick or myself know at some point.

That way we could make the ecosystem more consistent, prevent duplicated functionality across extensions

This was the initial idea for Symphonists. Conflict resolution between devs, and highlighting when things have been duplicated.

Great idea Jens. More generic (descriptive) naming would be a good idea in any case. Also: if several related extensions 'share' a common naming I think we should expect (require) them to be compatible.

Also: if several related extensions 'share' a common naming I think we should expect (require) them to be compatible.

True for multilingual_* extensions.

I only use the hash validation in my forms, so my motivation to update and test the other spam protection extensions as well is not very high.

But if there are any volunteers (if the original developer is no longer commited or too busy) to take care of the other extensions, I'm quite happy to help with compatibility issues and to discuss how to make the different extensions work more consistently.