SpamFireWall process

  • Resolved crawford4

    (@crawford4)


    2 weeks, 4 days ago

    Please can you explain how the SpamFireWall works? I am running the 7-day trial and I am considering signing up to a subscription.

    I know that the SpamFireWall blocks certain IPs, but this cannot be happening at the server level because CleanTalk does not have access to my server and there is no change in my .htaccess file. This is WordPress, so for anything clever to happen the plugin must load, which means WordPress will be bootstrapping every time. Is there really any significant saving of server resources?

    If I use an efficient caching mechanism, the spambots will only be accessing the cached version of my site, which will not be nearly as draining on server resources as bootstrapping WordPress every time they visit, just to see if they are bots and then block them!

    Please explain,
    Thank you,
    Charles

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Support amagsumov

    (@amagsumov)

    2 weeks, 4 days ago

    Hello @crawford4,

    Thank you for your questions.

    The SpamFireWall operates at the website level, intercepting HTTP requests the moment a user or bot attempts to visit your site. Each request is checked against the CleanTalk database. If the user is identified as a spambot, then its request is blocked immediately. In these cases, the request is stopped before it reaches WordPress, preventing unnecessary processing.

    Speaking of caching, even when a bot visits a cached page, your server still consumes resources to transfer that content. By using SpamFireWall, you block these bots entirely, which reduces the overall load on your server.

    Thank you.

    Thread Starter crawford4

    (@crawford4)

    2 weeks, 4 days ago

    That doesn’t make sense! How does the SpamFireWall intercept an HTTP request? The SpamFireWall cannot run before WordPress loads because the SpamFireWall is part of the CleanTalk plugin, which depends on WordPress loading.

    Thread Starter crawford4

    (@crawford4)

    2 weeks, 4 days ago

    This is how I understand it:

    1. HTTP request from spambot to mysite.com/non-existent-page;
    2. WordPress bootstraps via index.php, loading all plugins;
    3. CleanTalk plugin inspects the request and identifies the remote IP;
    4. If identified as spam, CleanTalk prevents any pages being displayed.

    Without CleanTalk:

    1. HTTP request from spambot to mysite.com/non-existent-page;
    2. WordPress bootstraps via index.php, loading all plugins;
    3. WordPress cannot find the requested page and presents a 404 page.
    Plugin Support amagsumov

    (@amagsumov)

    2 weeks, 4 days ago

    You are correct. Although the plugin is loaded with WordPress, SpamFireWall executes very early in the WordPress boot process, well before themes and other plugins are loaded, which has virtually no impact on site performance.

    Thread Starter crawford4

    (@crawford4)

    2 weeks, 3 days ago

    Ah, I see. Thank you for this explanation.

    Plugin Support amagsumov

    (@amagsumov)

    2 weeks, 3 days ago

    Happy to help!

    Plugin Support dimitrycleantalk

    (@dimitrycleantalk)

    1 week, 1 day ago

    Hello.
    We haven’t heard back from you in a few days, so I’m going to mark this thread as “resolved”.
    If you have any further questions, you can start a new thread or contact us via our private Ticket System: https://cleantalk.org/my/support/open.

Viewing 7 replies - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.