View Issue Details

IDProjectCategoryView StatusLast Update
0021028mantisbtadministrationpublic2016-07-19 15:59
Reporterdregad Assigned To 
Status newResolutionopen 
Summary0021028: Loosen or remove antispam limit based on user seniority

As discussed by e-mail following recent wave of spam attacks.

We should implement logic that improves our antispam protection, without negatively affecting "good" users.

One possibility would be to give some kind of "rating" to users, based on how long ago they registered, and/or how many issues / comments they posted. The rule to calculate this rating is to be discussed.

We could then use this rating to have differentiated antispam behavior, e.g. if it's high enough:

  • reduce or remove antispam post rate limit
  • allow specific, restricted actions (e.g. use mass-update functions in view issues page)
TagsNo tags attached.




2016-07-18 17:55

developer   ~0053637

Last edited: 2016-07-18 17:55

View 2 revisions

Some thoughts to start discussion

function get_user_reputation() {
$t_reptutation = 3 number_of_created_issues + 1 number_of_added_notes;

Don't count issues and notes that have been created the last n days.

# This is to exclude the latest spam that might have found it's way into the system. 
# 2 days could be the default.
# e.g. set to 1 day for projects where administrator is watching on a daily basis.
# set to 7 days for projects where administrator is able to check just on time a week.


function antispam_check() {

if( access_get_global_level() > config_get( 'default_new_account_access_level' ) ) {

$t_antispam_max_event_count = get_user_reputation();

# Make sure user has at least one more event to add before exceeding the limit, which will happen
# after this method returns.
$t_antispam_time_window_in_seconds = config_get( 'antispam_time_window_in_seconds' );
if( history_count_user_recent_events( $t_antispam_time_window_in_seconds ) < $t_antispam_max_event_count ) {

error_parameters( $t_antispam_max_event_count, $t_antispam_time_window_in_seconds );




2016-07-18 22:55

manager   ~0053639

@atrol the concept makes sense. But doesn't get_user_reputation() return 0 for new users, hence, they can't add any issues or notes to start with?



2016-07-19 02:33

developer   ~0053640

they can't add any issues or notes to start with?
Yes, that's the most secure way to avoid spam.

Joking aside, I got aware of it when going to bed, but too late to correct it.

We could add config_get( 'antispam_max_event_count' ) to the reputation.
After that we could avoid expensive history_count_user_recent_events call if reputation is greater than a certain value (e.g. 2*antispam_max_event_count)



2016-07-19 12:46

reporter   ~0053657

How about twisting the logic a bit and marking the issues and comments untrusted users create as private?

Then we could manually 'vet' new users and allow them to create public issues and comments. This of course requires some new admin pages, and maybe a way of making issues that were once private public ... Maybe not the best idea



2016-07-19 15:59

developer   ~0053659

This is similar to what I have configured in our forum.
The first posts of new users are not published but go through a so called mederation queue.
Users can post without moderation after two published posts.
If a user wants start spamming, there are just a few clicks to delete the user including all posts.

I am not sure if using "private" for two different things ("private" or "not published") is a good idea.
Maybe unpublished/public/private as possible values would be needed to implement this approach.

Issue History

Date Modified Username Field Change
2016-05-30 05:18 dregad New Issue
2016-07-18 17:55 atrol Note Added: 0053637
2016-07-18 17:55 atrol Note Edited: 0053637 View Revisions
2016-07-18 22:55 vboctor Note Added: 0053639
2016-07-19 02:33 atrol Note Added: 0053640
2016-07-19 12:46 rombert Note Added: 0053657
2016-07-19 15:59 atrol Note Added: 0053659