5 new anti-spam plugins from CleanTalk

We continue blogging about our work and will talk about our work in it. To begin with, that will tell you about what we have done in 2017. Over the past year, we have developed several anti-spam modules for CMS, which I will describe in more detail.

Why modules and not the API. First, they allow users to quickly and easily connect to the service. Second, not all users have the knowledge to connect the API. Third, the modules have a management interface, which makes it easier to use.

A little about the service itself: CleanTalk is a cloud-based service to protect websites from spam, provides a simple and convenient form of comment/registration for visitors, which will not require the visitor to prove that he/she is a person that saves time and resources spent on moderation and verification of questionable users or comments. All requests are stored in the cloud, including blocked ones, which helps to prevent data loss.

Additional features: SpamFireWall – “soft” blocking of POST and GET requests over IP and subnet masks (soft – if the user was mistakenly added, then after 1 second will be redirected to the page of the site).

How it works: The anti-spam module installed on the website transmits the behavior parameters of the visitor, browser, IP / email and message text. These parameters are evaluated and the service decides whether to post the message or define it as spam and reject it. Based on these checks, the service creates its own list of IP / Email addresses used by spambots. In the blacklist are added not only to IP / Email, but also domains sites promoted through spam. All this happens automatically and does not require any action from the site administration.

MODX Anti-Spam Plugin

The module was developed at the request of several clients and provides protection from spam for registrations, comments, feedback forms.

For the development of MODX, there is a fairly good documentation. For those who start developing and getting acquainted with MODX for the first time, it would be useful to add an example of creating the first simplest plugin (build your own first plugin) to the documentation, which greatly simplifies the process. The development process itself took 3-4 days, together with related tasks.

Adding the module to the official catalog did not cause any difficulties, everything was quite simple and understandable. Moderation took about a week after sending the module, waited 5-6 days and wrote to the technical support to find out at what stage and how long to wait, and the next day the module was published. It is not known whether this is due to treatment or not.

MyBB Anti-Spam Plugin

There are no problems with the documentation, everything is clear and there are no questions. The same with the development.

With the placement in the catalog, it is more difficult, it is necessary to understand the interface – it is not very convenient, but the worst thing is moderation of new plugins. Having sent the module for moderation in June 2017, we are still waiting for it to be published in the catalog. In general, the situation is similar to the directory phpBB, there also have to wait for months.

We decided to follow the advice of one of the users and create a topic on the forum, in the plugins section, added a description, links to the module.

OpenCart Anti-Spam Plugin

With documentation for development under this CMS, there are problems, it almost is not present. Good documentation was found here, for which many thanks to the compilers. To develop, you need vQmod and understanding MVC. In the rest, there is nothing complicated.

Quite a convenient interface for the marketplace, everything is clear and fast. Complexities with the addition did not arise.

XenForo 2 Anti-Spam Plugin

As for the developer documentation, even though XF2 is still a beta version, the documentation for it is one of the best. There were no difficulties with the development. The only thing is not entirely clear why automatic hash file creation (hashes.json) is done when the plugin is loaded and in the end each time you have to manually do this by the command.

The interface of the marketplace is convenient. There is no plugin moderation before publishing, plugins are moderated after you publish the plugin. This is probably not very convenient, as the version may contain errors, while the plugin will have time to download. By our first version, we have received code comments and a notification that if we do not resolve, the plugin will be removed from the directory.

Universal Anti-Spam Plugin

Since the number of requests to connect the service to not very popular CMS is stable, besides, we regularly receive requests using the API integration. Since it will be expensive to develop each time a separate module, it was decided to make a universal plugin. Universal Anti-Spam plugin can be installed on any custom websites, content management systems and frameworks. If the user has no programming experience to connect the API to the site, this will be the best solution for protecting the site from spam.

How it works?

The CleanTalk installer adds its code to the index.php file. When the visitor fills in and submits the form, the plugin intercepts the form data and finds the email, the message itself and adds some other parameters to them and sends them to the CleanTalk cloud, except when the form has been found banned for sending data (they are stitched into the plugin and can not changed). After receiving a response from the server, the plugin skips or forbids further execution (displaying a message about the reasons for the lock).

After analyzing the parameters sent, CleanTalk servers decide whether the request should be blocked or allowed. Since the universal CleanTalk libraries were used in writing, it was necessary to organize only the installation and interception of forms. To be honest, we had to rewrite the libraries so that they worked on pure PHP and add exceptions for some fields, such as registering or recovering passwords or paying with cards.

For each client’s request, we do a test with its CMS, complementing the plugin to work specifically with this CMS. Therefore, at the moment we do not want to make new plugins, as it entails overhead costs in the form of loss of time to support versions up to date.

The plugins themselves:





Universal plugin

At the moment, we do not plan to expand the range of plugins, only support and development of the current functionality. We hope that the universal plugin will be able to close these gaps, as it is easier to modify one plugin than to do each time a new one.

Leave a Reply

Your email address will not be published. Required fields are marked *