I’ve had to think about spammers a lot lately, since nothing seems to stop them from creating accounts on our OJS journals. Yes, we can get rid of the accounts, but the damage is already done. I wonder if it might be possible to make it mandatory for a journal manager to approve each account before it becomes available for public viewing? This would remove the motivation for creating spam accounts, as their purpose seems to be to display links to their nefarious web sites.
See if anything indicated in this document helps you:
https://docs.pkp.sfu.ca/admin-guide/en/securing-your-system#managing-spam
As the creation of accounts for spam is automated, I have doubts if they would stop being created even if they need moderation to be active.
I have already carried out the spam control measures in your link, as have many other OJS administrators, without success. Since it is not possible to stop spammers from registering accounts, I think it would be helpful to make it unprofitable for them. In addition, it is embarrassing and possibly makes us liable when our legitimate users find malware/pornography links in our journals’ user profiles.
Hi @glenng,
What version of OJS are you using? (Please include this in your posts.)
Regards,
Alec Smecher
Public Knowledge Project Team
There’s a bit of code for blocking user profile images suggested in this post: [OJS 3.x] Misuse of profile image may cause legal action - #8 by NateWr
Alec, we have six journals at version 2.4.8.5 and one each at 3.3.0.6 and 3.3.0.2. Two of the 2.4.8.5 journals collect the most spam accounts.
Hi @glenng,
You’re probably seeing automated attempts to exploit an old issue (see JSON responses do not consistently set content-type to application/json · Issue #3944 · pkp/pkp-lib · GitHub for details) that has been corrected already in 2.4.8-5. Automated user registrations try to seed spam content that shows up in the getInterests URL endpoint and can be indexed by search engines.
I’m not aware of any current payoff for creating spam accounts; spam content is not displayed anywhere that search engines can index. If you see somewhere that it is, please let us know.
There is a require_validation option that works somewhat like you describe – check config.inc.php to see if it appears. If not, you may need to upgrade. (There are various other measures as pointed out above – ReCAPTCHA, the honeypot plugin in the Plugin Gallery, etc – but these will all require you to upgrade beyond 2.x.)
Regards,
Alec Smecher
Public Knowledge Project Team
Alec, thanks for your response. I just realized that the spam profiles are not publicly viewable, so this is not as big an issue as I thought. Sometimes we get so interested in the details that we forget to look at the big picture.
2 Likes