NodeBB anti spam

[finid]

@psychobunny said:

an upvote/downvote plugin could ideally flag someone as a spammer after they reached X amounts of downvotes and then hide their posts. but if that wasn't in the core already then I'd need your plugin for that plugin to work.

Instead of depending on the number of down votes to hide a post, how about adding a Flag_This_Post feature that can be used to alert the admin that a post is spam and/or requires moderation. The up/down vote feature may then be reserved solely for judging the usefulness of a post to a topic or a topic itself. Does that make sense?

[Xiph]

A very simple solution to prevent a lot of automated signups without requiring a Captcha or Question/Answer form:

1. Honeypots. Simply have some input elements with the name attribute being something like username, password and the like and an id attribute either equal to or containing the same phrase. These inputs should not be visible to the user and contain no data, so whenever something is entered into these forms, you'll know it's a bot.
   Ideally these elements or their container should also include the actual labels shown to the user, to fool the bots looking at the label rather than the input in an attempt to bypass the prevention described in 2.
2. Have the actual input elements be unique to each session. Simply make the name and id attributes of the actual input forms be unique to each session. Shouldn't be too difficult, yet still blocks a lot of scripts that do not take this into consideration. This should not apply to the honeypot inputs described in 1., for obvious reasons.
3. Randomize the order of the input elements. Some bots look at the order of the input elements rather than their name and id attributes. Simply randomizing it should prevent this.

[bentael]

@Xiph all this is good, but doesn't prevent a targeted-script

[julian]

@bentael @Xiph unfortunately, no amount of automated prevention will stop people from hiring people from the third world to register accounts and post spam... but at least it'll weed out the automated ones!

[Xiph]

@bentael said:

@Xiph all this is good, but doesn't prevent a targeted-script

Well, the theory of using those three methods of prevention combined is that only A. a regular, normal human (sorry, mutants and/or half-cyborg jellyfish-themed superheroes) or B. a bot rendering the entire page can register.
Having to actually render the page does massively increase the cost of creating spam accounts though and as @julian said, if you really really want to spam you can always just have a human register, or do it yourself. None of this removes the need for a kind-of Akismet-ish thing as another layer of protection, it just massively reduces the amount of automated registrations.

EDIT It seems like XenForo does in fact allow you to check all posts with Akismet.

[fantapop]

@bentael You still working on this?

[bentael]

@fantapop this plugin is currently blocked while waiting for some desgin descisions. i'll chat with NodeBB team to see whats the best way to go about this.

[julian]

req.ip passed into user registration now, and @bentael, you can use my honey pot plugin to query IPs for validity.

[bentael]

@fantapop I just released a sort of working version,
https://www.npmjs.org/package/nodebb-plugin-spam-be-gone
this one only work with the Honeypot Project, i would appreciate some testing help. i didn't get a chance to actually test real IPs, only tested with 127.0.0.1 which is close to useless. Tomorrow, I'll try to hardcode fake spammy IPs for better coverage.

@julian, I got the Honeypot plugin to work, nice job on that nodejs module, but that only works for User registration, I was aiming for post creations as well,

I need a hook on Post.create and/or Topic.post or Topic.reply to get a check with Akismet, but Akismet requires at least these 3

            user_ip: req.ip ,
            user_agent: req.get('User-Agent'),
            blog: req.host,

I could also use
postData.user.username and postData.content

let me know what you think is the best approach and I can add the hooks and submit a PR.

[bentael]

So, I don't know if you want to plumb through the req object, or maybe implement the filter on a higher level, maybe at the POST /api/{route} handler

[julian]

Seems legit.

• Topic.post and Topic.reply are both standalone functions, but to follow DRY, Topic.post calls Topic.reply
• Topic.reply calls Posts.create

So I believe putting a hook in at the Posts.create level (here, as the first waterfall function) would be easiest.

I suggest filter:posts.check or filter:posts.validate as a name. filter:posts.save is already there, but the post creation process has already begun, so it is used mostly for munging data after it is destined to enter the database.

[bentael]

@julian ok, Post.create sounds like a good place, but can I guarantee that the req object is going to be plumbed in from all the paths?

[julian]

Hm... since posting is done via web sockets, we don't have the same data we would have in req... would have to example the socket data and see what we have to work with...

[bentael]

ok i'll investigate and post back

[baris]

I don't think we should put it in Posts.create as that is the internal function used by importers as well, Topics.reply seems like a better place as it is the one that is called by users and Topics.post calls that too.

[bentael]

okay.png

[julian]

Haha good thing we have @baris watching out for the wrong things I say

[bentael]

https://github.com/akhoury/nodebb-plugin-spam-be-gone updated, but blocked by https://github.com/designcreateplay/NodeBB/pull/1443

[julian]

@bentael Really glad to see the evolution of NodeBB's first anti-spam plugin!!