Moderation, blacklisting, and flooding

[johnjamesjacoby]

With spam an ever increasing concern, BuddyPress is currently ill equipped to prevent spam or unapproved content before it starts. As such, BuddyPress core needs functions that can check any submitted data against WordPress core's illegal keys, as well as protect any child component from flooding.

[johnjamesjacoby]

(In [5272]) Introduce bbp-core-moderation.php to provide basic functions for checking submitted content against illegal keys and flooding. See #3732.

[johnjamesjacoby]

(In [5273]) Change filter names so they match function names in bbp-core-moderation. See #3732.

[johnjamesjacoby]

(In [5274]) Use new _core_ prefixed function names in bbp-core-moderation.php. See #3732.

[johnjamesjacoby]

(In [5277]) Add moderation keys and blacklist keys filters to Activity stream component. Introduce function for gathering the activity types that should be checked, and default to updates and comments per the Akismet extension. See #3732.

[johnjamesjacoby]

Functions are in, activity stream is using it. Other components can take advantage of this at a later date. Note that bbPress 2 already uses these. Closing as fixed.

[patricksaad]

The function bp_core_check_for_flood in bbp-core-moderation.php is not hooked to anything. No flood control on activity page.

[tw2113]

Can verify in trunk that comment:7 above is accurate. We still are not hooking bp_core_check_for_flood() into anything. Not quite sure offhand where we would want to.

[r-a-y]

comment:7 is correct.

There is reference to a _bp_throttle_time option and a _bp_last_posted user meta being saved, but we do not use any of this at the moment.

Could piggyback onto the WP comment moderation throttle time to start. The _bp_last_posted user meta entry might be problematic because it could be too general. For example, components might want to have a separate throttle based on their content instead of a site-wide throttle.

[johnjamesjacoby]

These were lifted straight from bbPress 2's implementation, which had changed slightly since this was put in, so we'd want to update it.

I think a global throttle period for the user is a fine first step, and if individual components want to have their own specific throttles, those could be implemented later.

The idea with this is to prevent spamming of any repeating action, like sending 50 friend requests a minute kinda thing, and per-component settings aren't necessary to meet that requirement.