We decided to continue blogging and we will talk about our work in it. To begin with, we’ll tell you about what we did in 2017. Over the past year, we have developed several anti-spam modules for CMS, which I will discuss in more detail.
Why modules, but not API. First, they allow users to quickly and easily connect to the service. Secondly, not all users have enough knowledge to connect the API. Third, the modules have a management interface, which simplifies use.
A little about the service itself : CleanTalk is a cloud service for protecting web sites from spam, provides a simple and convenient comment / registration form for visitors, which will not require the visitor to prove that he is human, which saves time and resources spent on moderation and checking questionable users or comments. All requests are stored in the cloud, including blocked ones, which helps prevent data loss.
Additional features: blocking POST requests by country, IP and email, blocking by “Stop Words”, “SpamFireWall” - soft ”blocking POST and GET requests by IP and by subnet masks (soft - if the user was mistakenly added, then after 1 sec will be redirected to the site page).
How it works : The Antispam module installed on the website transmits the parameters of the visitor, browser, IP / email and the text of the message. These parameters are evaluated, and the service decides whether to post a message or define it as spam and reject. Based on such checks, the service generates its own list of IP / Email addresses used by spam bots. Not only IP / Email is added to the black list, but also the domains of sites promoted through spamming. All this happens automatically and does not require any action from the site administration.
The module was developed upon requests from several clients and provides protection against spam for registrations, comments, feedback forms.
There is pretty good documentation for development under MODX. For those who are starting development and getting acquainted with MODX for the first time, it would not hurt to add to the documentation an example of creating the first simplest plug-in (build your own first plugin), which greatly simplifies the process. The development process itself took 3-4 days, along with related tasks.
Adding a module to the official catalog did not cause any difficulties, everything was quite simple and clear. The moderation took about a week, after sending the module they waited 5-6 days and wrote to technical support, 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 connected with circulation or not.
There are no problems with documentation, everything is clear and does not cause questions. The same with the development.
With the placement in the directory is more difficult, it is necessary to understand the interface - it is not very convenient, but the worst thing is the moderation of new plug-ins. 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.
With the documentation for the development of this CMS there are problems, it is almost gone. Good documentation was found here , for which many thanks to the compilers. Development will require vQmod and an understanding of MVC. Otherwise, nothing complicated.
Quite convenient marketplace interface, everything is clear and fast. Difficulties with the addition did not arise.
With regard to documentation for developers, despite the fact that XF2 is still a beta version, the documentation for it is one of the best. Difficulties with the development was not. The only thing that is not entirely clear is why the automatic generation of file hashes (hashes.json) is done when the plug-in is loaded, and as a result, each time you have to manually do it with a command.
The interface of the marketplace is convenient. There is no moderation of plugins before publication, plugins are moderated after you have published a plugin. This is probably not very convenient, since the version may contain errors, while the plugin will already have time to download. To our first version we received comments on the code and a notice that if we do not eliminate it, the plugin will be removed from the catalog.
Since the number of requests to connect the service to a not very popular CMS is stable, moreover, we regularly receive requests using the integration API. Since it would be costly to develop a separate module each time, it was decided to make a universal plug-in. Universal Anti-Spam plugin can be installed on any user sites, 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 to protect the site from spam.
How it works?
The CleanTalk installer adds its code to the index.php file. When a visitor fills in and submits the form, the plug-in intercepts the form data and finds the email, the message itself and adds some other parameters to it and sends them to the CleanTalk cloud, except for cases when data that is prohibited to be sent has been found in the form (they are sewn into the plug-in and cannot changed). After receiving a response from the server, the plugin skips or denies further execution (displaying a message about the reasons for blocking).
After analyzing the sent parameters, the CleanTalk servers decide whether the request should be blocked or allowed. Since the CleanTalk universal libraries were used when writing, it was necessary to organize only the installation and interception of forms. To be honest, I had to rewrite the libraries so that they worked in pure PHP and added exceptions for some fields, such as registration or password recovery, or payment by cards.
For each customer request, we do a test with his CMS, complementing the plugin to work specifically with this CMS. Therefore, at the moment we do not want to make new plugins, as this entails overhead, in the form of a loss of time to keep the versions up to date.
The plugins themselves :
MODX
Mybb
Opencart
XenForo2
Universal Plugin
At the moment we do not plan to expand the line of plug-ins, only the support and development of the current functionality. We hope that the universal plug-in will be able to close these gaps, since it is easier to modify one plug-in than to do something new every time.
Source: https://habr.com/ru/post/348616/
All Articles