Receiving thousands of dummy spam comments

My journal (OJS 2.4.8) has been fed with thousands of spam comments
I’ve disabled user registration feature, so I don’t ge more unwanted users. Furthermore, I have disabled comments feature.

  1. Can I delete the comments in database or this will be affecting referential integrity?
  2. How could I identify what users registered in the journal and posted the comments, so I can delete them as well?

Thanks in advance for your reply


Hi @jascanio,

I think it is okay to delete comments in the database because comments are not integral to a submission record (the way a user ID is).

It should be easy for you to identify spam users by their email addresses, which will probably be a string of nonsensical numbers and letters with an uncommon domain. You can’t delete user records in OJS but you can merge spam user accounts into one account.

Amanda Stevens
Public Knowledge Project Team

Hi @astevens,
Thanks for your reply.

Best regards

But how to prevent it? I cannot disable user registration and adding comments functionality. I have recaptcha v2 on and require_validation set to on and still I receive hundreds of spam comments and user accounts! My OJS is

We encountered this problem and applied a couple of additional mechanisms to address it:

A prior sprint proposed an enhancement which would require a Journal Manager to optionally approve each new user registration. Code for this was attached to an issue here, but not pulled into a release yet:

Hi @ctgraham,

thanks for these notes. Approval seems ok, but for hundreds of registration everyday this may be challenging (or maybe if accompanied by other solution).

And is there any way to block these bots in .htaccess simply? Are they easy to track down? Maybe a list of these bots published on the website would be some solution?

If you have a specific user agent or ip address range that you want to block, this can be performed with a .htaccess or similar webserver configuration.

From my experience earlier this year, we were being hit by some sort of distributed botnet or mechanical turk operation. We were unable to find an appropriate set of user agent strings and ip addresses which we could use as the basis for an .htaccess or similar configuration block.

Hi ctgraham,

For my 2 cents, I have seen registered users required to click on link to validate, and link received via registered email, will that be an effective solution.



There is a response here for my question Spam account under Users and Roles - #7 by dung