-
AbuseIPDB Integration module
DOWNLOAD PAGE: https://www.zen-cart.com/downloads.php?do=file&id=2371
I've developed a new module that integrates AbuseIPDB with Zen Cart, and I'm making it available for everyone to use.
What is AbuseIPDB? It's a community-based project that collects and shares data about abusive IP addresses. By integrating with their API, my module allows you to protect your e-commerce website from potentially harmful visitors by checking the confidence score of their IP address and blocking access if it exceeds a predefined threshold.
The module also includes several useful features, such as caching to reduce the number of API calls, a test mode for debugging, and logging to monitor blocked IPs. You can also manually whitelist or blacklist IP addresses to have greater control over access to your site.
I've tested the module and it's ready for use, so if you're interested in trying it out, it's attached: AbuseIPDBO v1.0.0
If you have any questions or encounter any issues while using the module, please don't hesitate to reach out to me. I hope this module proves useful to you.
marcopolo
-
1 Attachment(s)
Re: AbuseIPDB Integration module
Here is the module: AbuseIPDBO v1.0.0
-
Re: AbuseIPDB Integration module
Hi @marcopolo
Got this all set up on my 1.5.6c store, api key works & blocking is working. I am however getting a headers already sent error when using it. My logs folder fills up with every visit & page view, so I’ve had to disable the plugin. Sample debug as follows (with api key removed)
Code:
[21-May-2023 18:14:44 Europe/London] Threshold: 50
[21-May-2023 18:14:44 Europe/London] Cache Time: 3600
[21-May-2023 18:14:44 Europe/London] Test Mode: false
[21-May-2023 18:14:44 Europe/London] Test IP:
[21-May-2023 18:14:44 Europe/London] Enable Logging: false
[21-May-2023 18:14:44 Europe/London] Log File Format: abuseipdb_blocked_Y_m.log
[21-May-2023 18:14:44 Europe/London] Log File Path: logs/
[21-May-2023 18:14:44 Europe/London] Whitelisted IPs:
[21-May-2023 18:14:44 Europe/London] Blocked IPs:
[21-May-2023 18:14:44 Europe/London] Checking cache for IP: 54.236.1.13
[21-May-2023 18:14:45 Europe/London] API call made for IP: 54.236.1.13 with score: 68
[21-May-2023 18:14:45 Europe/London] IP 54.236.1.13 blocked from API call
[21-May-2023 18:14:45 Europe/London] Request URI: /queen-crown-badge-p-712.html, IP address: 54.236.1.13
#1 header() called at [/home/brucebli/public_html/koolbadges.co.uk/includes/classes/observers/class.abuseipdb_observer.php:137]
#2 abuseipdb_observer->checkAbusiveIP() called at [/home/brucebli/public_html/koolbadges.co.uk/includes/classes/observers/class.abuseipdb_observer.php:19]
#3 abuseipdb_observer->update() called at [/home/brucebli/public_html/koolbadges.co.uk/includes/classes/class.base.php:103]
#4 base->notify() called at [/home/brucebli/public_html/koolbadges.co.uk/includes/templates/responsive_avonlee_contempo/common/tpl_header.php:4]
#5 require(/home/brucebli/public_html/koolbadges.co.uk/includes/templates/responsive_avonlee_contempo/common/tpl_header.php) called at [/home/brucebli/public_html/koolbadges.co.uk/includes/templates/responsive_avonlee_contempo/common/tpl_main_page.php:106]
#6 require(/home/brucebli/public_html/koolbadges.co.uk/includes/templates/responsive_avonlee_contempo/common/tpl_main_page.php) called at [/home/brucebli/public_html/koolbadges.co.uk/index.php:97]
--> PHP Warning: Cannot modify header information - headers already sent by (output started at /home/brucebli/public_html/koolbadges.co.uk/includes/templates/responsive_avonlee_contempo/jscript/jscript_framework.php:17) in /home/brucebli/public_html/koolbadges.co.uk/includes/classes/observers/class.abuseipdb_observer.php on line 137.
-
Re: AbuseIPDB Integration module
This is a common PHP error that usually happens when you attempt to send a HTTP header after some output has already been sent to the browser.
In this case, the output has been started at file jscript_framework.php on line 17, which is preventing the header modification in class.abuseipdb_observer.php on line 137.
The issue lies in the sequence of operations where some content was output before the headers could be completely set. This could be due to:
Printing some text or HTML before calling a header function.
A PHP or HTML file which has whitespace or an empty line before the opening PHP tag (<?php) or after the closing PHP tag (?>), if used.
A UTF-8 Byte Order Mark (BOM) at the beginning of one of the files.
Using echo, print, printf, or die functions before setting headers.
To fix this issue, check the file /home/brucebli/public_html/koolbadges.co.uk/includes/templates/responsive_avonlee_contempo/jscript/jscript_framework.php specifically at line 17 and make sure there's no output before the headers are set in the file class.abuseipdb_observer.php.
If this doesn't solve your problem, consider using output buffering by placing ob_start(); at the beginning of your PHP script. This function will turn output buffering on. While output buffering is active no output is sent from the script (other than headers), instead the output is stored in an internal buffer. You can then use ob_end_flush(); or ob_end_clean(); at the end of the script to send output and turn off output buffering. However, it's better to solve the actual problem of why output is being sent too early, if possible.
-
Re: AbuseIPDB Integration module
Let me know what module is using the file: jscript_framework.php as it is not part of this modules files, if you can upload the file here so I can take a look at the code and see what it is doing.
-
Re: AbuseIPDB Integration module
The file itself is by lat9 - I personally can't remember which plugin it came from, but I think it might be something to do with the responsive avonlee contempo modified themed I'm running.
File contents as follows
Code:
<?php
/**
* @package admin
* @copyright Copyright 2003-2017 Zen Cart Development Team
* @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
* @version $Id: Author: zcwilt lat9 Modified in v1.5.6 $
*/
?>
<script type="text/javascript"><!--//<![CDATA[
if (typeof zcJS == "undefined" || !zcJS) {
window.zcJS = { name: 'zcJS', version: '0.1.0.0' };
};
zcJS.ajax = function (options) {
options.url = options.url.replace("&", unescape("&"));
var deferred = jQuery.Deferred(function (d) {
var securityToken = '<?php echo $_SESSION['securityToken']; ?>';
var defaults = {
cache: false,
type: 'POST',
traditional: true,
dataType: 'json',
timeout: 5000,
data: jQuery.extend(true,{
securityToken: securityToken
}, options.data)
},
settings = jQuery.extend(true, {}, defaults, options);
if (typeof(console.log) == 'function') {
console.log( settings );
}
d.done(settings.success);
d.fail(settings.error);
d.done(settings.complete);
var jqXHRSettings = jQuery.extend(true, {}, settings, {
success: function (response, textStatus, jqXHR) {
d.resolve(response, textStatus, jqXHR);
},
error: function (jqXHR, textStatus, errorThrown) {
if (window.console) {
if (typeof(console.log) == 'function') {
console.log(jqXHR);
}
}
d.reject(jqXHR, textStatus, errorThrown);
},
complete: d.resolve
});
jQuery.ajax(jqXHRSettings);
}).fail(function(jqXHR, textStatus, errorThrown) {
var response = jqXHR.getResponseHeader('status');
var responseHtml = jqXHR.responseText;
var contentType = jqXHR.getResponseHeader("content-type");
switch (response)
{
case '403 Forbidden':
var jsonResponse = JSON.parse(jqXHR.responseText);
var errorType = jsonResponse.errorType;
switch (errorType)
{
case 'ADMIN_BLOCK_WARNING':
break;
case 'AUTH_ERROR':
break;
case 'SECURITY_TOKEN':
break;
default:
alert('An Internal Error of type '+errorType+' was received while processing an ajax call. The action you requested could not be completed.');
}
break;
default:
if (jqXHR.status === 200) {
if (contentType.toLowerCase().indexOf("text/html") >= 0) {
document.open();
document.write(responseHtml);
document.close();
}
}
}
});
var promise = deferred.promise();
return promise;
};
zcJS.timer = function (options) {
var defaults = {
interval: 10000,
startEvent: null,
intervalEvent: null,
stopEvent: null
},
settings = jQuery.extend(true, {}, defaults, options);
var enabled = new Boolean(false);
var timerId = 0;
var mySelf;
this.Start = function()
{
this.enabled = new Boolean(true);
mySelf = this;
mySelf.settings = settings;
if (mySelf.enabled)
{
mySelf.timerId = setInterval(
function()
{
if (mySelf.settings.intervalEvent)
{
mySelf.settings.intervalEvent(mySelf);
}
}, mySelf.settings.interval);
if (mySelf.settings.startEvent)
{
mySelf.settings.startEvent(mySelf);
}
}
};
this.Stop = function()
{
mySelf.enabled = new Boolean(false);
clearInterval(mySelf.timerId);
if (mySelf.settings.stopEvent)
{
mySelf.settings.stopEvent(mySelf);
}
};
};
//]] --></script>
-
1 Attachment(s)
Re: AbuseIPDB Integration module
I'm not sure why your receiving that error, try this file in place of the one your using now and see if it resolves the issue, see attached AbuseIPDBO_custom_file.zip
-
Re: AbuseIPDB Integration module
Thanks marcopolo
With that updated file I still get the headers already sent error
Code:
[21-May-2023 21:19:03 Europe/London] Request URI: /teal-heart-boss-bridesmaid-badge-p-6746.html, IP address: 54.236.1.13
#1 header() called at [/home/brucebli/public_html/koolbadges.co.uk/includes/classes/observers/class.abuseipdb_observer.php:144]
#2 abuseipdb_observer->checkAbusiveIP() called at [/home/brucebli/public_html/koolbadges.co.uk/includes/classes/observers/class.abuseipdb_observer.php:19]
#3 abuseipdb_observer->update() called at [/home/brucebli/public_html/koolbadges.co.uk/includes/classes/class.base.php:103]
#4 base->notify() called at [/home/brucebli/public_html/koolbadges.co.uk/includes/templates/responsive_avonlee_contempo/common/tpl_header.php:4]
#5 require(/home/brucebli/public_html/koolbadges.co.uk/includes/templates/responsive_avonlee_contempo/common/tpl_header.php) called at [/home/brucebli/public_html/koolbadges.co.uk/includes/templates/responsive_avonlee_contempo/common/tpl_main_page.php:106]
#6 require(/home/brucebli/public_html/koolbadges.co.uk/includes/templates/responsive_avonlee_contempo/common/tpl_main_page.php) called at [/home/brucebli/public_html/koolbadges.co.uk/index.php:97]
--> PHP Warning: Cannot modify header information - headers already sent by (output started at /home/brucebli/public_html/koolbadges.co.uk/includes/templates/responsive_avonlee_contempo/jscript/jscript_framework.php:17) in /home/brucebli/public_html/koolbadges.co.uk/includes/classes/observers/class.abuseipdb_observer.php on line 144.
-
Re: AbuseIPDB Integration module
Ok.
I tried renaming the jscript_framework.php temporarily to jscript_framework.php.bak just to see if the error went away & it then caused the same error with the jscript_plugin_structured_data.php script, so it would appear the code isn't playing well with other plugins.
-
Re: AbuseIPDB Integration module
I would check your tpl_header.php and tpl_main_page.php files against their originals and see if any modification made to them is causing the issue.
The issue is that you're encountering a "headers already sent" error. This is often caused when you attempt to send a header after the HTTP body content has started to be output. Since those files are listed in the log they may have something to do it it:
To fix this, you should check these lines in tpl_header.php and tpl_main_page.php and ensure there is no output before the header() function is called. Output can be any HTML outside PHP tags, any echo or print statement, or even a PHP closing tag (?>) followed by a newline or space.
Hope that helps
-
Re: AbuseIPDB Integration module
That file jscript_framework.php is part of zencart, I have the same file and it works on my store so I do not think it is that. Check the two files I outlined the previous post. If those are modified try using the originals and troubleshoot and see if that is your issue.
-
Re: AbuseIPDB Integration module
FWIW, that "headers already sent" issue is usually associated with a file (usual culprits are language files) that has an extra space after the PHP 'end', e.g.
... where there is a blank line after the <?.
-
Re: AbuseIPDB Integration module
Thanks both of you.
I checked tpl_header.php and tpl_main_page.php against originals and there are changes to do with my template in use compared to stock files from Zen Cart, but the core of the files are the same. I tried, just to test, dropping in the standard files without modifications & the error persists.
I also went through files looking for extra whitespace & couldn't find anything. The strange thing is, this site has been running for a long time & has quite a few plugins which work perfectly together. This is the first plugin I’ve used which fills up the log files, so it would seem if the error exists in one of my existing files, it doesn't affect any of the other plugins as the only file I ever get in logs is if a square payment is declined or fails.
I spent a few hours last night combing through files trying to find anything that could be issuing a header response before tpl_header.php, but I couldn't find anything. I'll just have to leave it disabled for now which is a shame.
-
Re: AbuseIPDB Integration module
Thanks for this great plugin, nice work!
Is there a reason why you redirect blocked IPs to the page_not_found page? I think a 410 redirect would be more suitable.
I have changed in includes/classes/observers/class.abuseipdb_observer.php the three instances of:
Code:
header('Location: /index.php?main_page=page_not_found');
exit();
to:
Code:
header('HTTP/1.0 410 Gone');
zen_exit();
@johnjlarge
could be a fix for your headers already sent issue as well
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
webchills
Thanks for this great plugin, nice work!
Is there a reason why you redirect blocked IPs to the page_not_found page? I think a 410 redirect would be more suitable.
I have changed in includes/classes/observers/class.abuseipdb_observer.php the three instances of:
Code:
header('Location: /index.php?main_page=page_not_found');
exit();
to:
Code:
header('HTTP/1.0 410 Gone');
zen_exit();
@johnjlarge
could be a fix for your headers already sent issue as well
Just tried with these changes, still no go for me. Still getting the headers already sent error.
-
Re: AbuseIPDB Integration module
So, I've found a way around this which works, are there any issues to doing it this way?
In the index.php file at the root of zen cart, adding the block code before allowing html_header.php to load makes the code work. Will this give me any issues downstream in the code flow?
Around line 40 of index.php I've added the code here
Code:
/**
* We now load header code for a given page.
* Page code is stored in includes/modules/pages/PAGE_NAME/directory
* 'header_php.php' files in that directory are loaded now.
*/
require($code_page_directory . '/' . $value);
}
/**
* We now load the html_header.php file. This file contains code that would appear within the HTML <head></head> code
* it is overridable on a template and page basis.
* In that a custom template can define its own common/html_header.php file
*/
// bof modification AbuseIPDB
if (ABUSEIPDB_ENABLED) {
$GLOBALS['zco_notifier']->notify('NOTIFY_HEADER_START');
}
// eof modification AbuseIPDB
require($template->get_template_dir('html_header.php',DIR_WS_TEMPLATE, $current_page_base,'common'). '/html_header.php');
/**
* Define Template Variables picked up from includes/main_template_vars.php unless a file exists in the
* includes/pages/{page_name}/directory to overide. Allowing different pages to have different overall
* templates.
*/
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
webchills
Thanks for this great plugin, nice work!
Is there a reason why you redirect blocked IPs to the page_not_found page? I think a 410 redirect would be more suitable.
I have changed in includes/classes/observers/class.abuseipdb_observer.php the three instances of:
Code:
header('Location: /index.php?main_page=page_not_found');
exit();
to:
Code:
header('HTTP/1.0 410 Gone');
zen_exit();
@johnjlarge
could be a fix for your headers already sent issue as well
Thank you glad you like it!
In regards to the redirect page I guess I thought giving it no information was better but maybe 410 option is better since it would indicate that the content is permanently gone and discourage further access attempts from the abusive IP addresses. It can also help search engines quickly remove the content from their indexes.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
johnjlarge
So, I've found a way around this which works, are there any issues to doing it this way?
In the index.php file at the root of zen cart, adding the block code before allowing html_header.php to load makes the code work. Will this give me any issues downstream in the code flow?
Around line 40 of index.php I've added the code here
Code:
/**
* We now load header code for a given page.
* Page code is stored in includes/modules/pages/PAGE_NAME/directory
* 'header_php.php' files in that directory are loaded now.
*/
require($code_page_directory . '/' . $value);
}
/**
* We now load the html_header.php file. This file contains code that would appear within the HTML <head></head> code
* it is overridable on a template and page basis.
* In that a custom template can define its own common/html_header.php file
*/
// bof modification AbuseIPDB
if (ABUSEIPDB_ENABLED) {
$GLOBALS['zco_notifier']->notify('NOTIFY_HEADER_START');
}
// eof modification AbuseIPDB
require($template->get_template_dir('html_header.php',DIR_WS_TEMPLATE, $current_page_base,'common'). '/html_header.php');
/**
* Define Template Variables picked up from includes/main_template_vars.php unless a file exists in the
* includes/pages/{page_name}/directory to overide. Allowing different pages to have different overall
* templates.
*/
That is fine for the index page however if one enters on a different page your not protected, that is why it is added to the tpl_header.php page since that will load on every page no matter the entry point.
-
Re: AbuseIPDB Integration module
Hi @marcopolo
I've just tested it, setting my own IP as the test mode IP & can confirm it works on subpages. As far as I'm aware the index.php always fires, then loads in templates, includes etc. It may be a more elegant way to load it, as the block will launch with minimal code being loaded, possibly reducing server load in the process. I chose index.php as according to the program flow in documentation it's the top level page which everything else loads from. With this being a blocking script, it would make sense to expose as little code/server resources as possible.
Program flow docs https://docs.zen-cart.com/dev/code/program_flow/
I also set the redirect as a 403 forbidden error as this seemed more appropriate for my usage.
Code:
// Redirect to the 404 page
header('HTTP/1.0 403 Forbidden');
zen_exit();
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
johnjlarge
Hi @marcopolo
I've just tested it, setting my own IP as the test mode IP & can confirm it works on subpages. As far as I'm aware the index.php always fires, then loads in templates, includes etc. It may be a more elegant way to load it, as the block will launch with minimal code being loaded, possibly reducing server load in the process. I chose index.php as according to the program flow in documentation it's the top level page which everything else loads from. With this being a blocking script, it would make sense to expose as little code/server resources as possible.
Program flow docs
https://docs.zen-cart.com/dev/code/program_flow/
I also set the redirect as a 403 forbidden error as this seemed more appropriate for my usage.
Code:
// Redirect to the 404 page
header('HTTP/1.0 403 Forbidden');
zen_exit();
Your perfectly fine then, apologies for the oversight regarding the index page. I wasn't aware that it loaded on every page. I use one of those SEO page optimizers that rename all my pages to .html pages so I never see the zencart page names. To regards to optimizing server load, the best solution would be to load it from the index page outlined within the flow documentation as you pointed out. A blocked IP, I assume they would just receive a blank page with no content loading from your site?
-
Re: AbuseIPDB Integration module
That's exactly it. A completely blank page with (in my case) a 403 response. I guess you could set a custom static 403 page via .htaccess to inform the user that their IP is blocked. I couldn't find what was throwing the headers already sent error when using your plugin, so I just worked backwards from the program flow documentation and added the check IP code as early as possible in the code base.
-
Re: AbuseIPDB Integration module
I've hit another issue. Even though I've signed up as a webmaster & put the button on my website to increase API calls to 5000 on abuseipdb.com, I've hit my ip lookup api limit within 3 hours of a 24-hour period. Does the plugin also cache clean IP's or will it simply look up the same clean IP on every page view, meaning each page view equals one api hit?
-
Re: AbuseIPDB Integration module
Yes, the plugin caches both clean and abusive IPs. It only makes an API call if the abuse score is not in the cache or if it has expired.
-
Re: AbuseIPDB Integration module
Instead of adding a new notifier (NOTIFY_HEADER_START) in includes/templates/YOUR_TEMPLATE/common/tpl_header.php you could also use the existing notifier NOTIFY_HTML_HEAD_START in includes/templates/YOUR_TEMPLATE/common/html_header.php and change in the observer class from NOTIFY_HEADER_START to NOTIFY_HTML_HEAD_START.
This way there is no change of existing core files required when installing the plugin.
-
Re: AbuseIPDB Integration module
I'm not sure if the caching is working correctly. I've woken up just now & almost exhausted my API limit for the day at 7:47am
I just enabled debug mode to check the logs & it would seem it's making a fresh call even for the same ip.
From the bottom of the first debug log
[25-May-2023 07:46:22 Europe/London] Checking cache for IP: 54.236.1.11
[25-May-2023 07:46:22 Europe/London] API call made for IP: 54.236.1.11 with score: 63
[25-May-2023 07:46:22 Europe/London] IP 54.236.1.11 blocked from API call
and then the second
[25-May-2023 07:46:39 Europe/London] Checking cache for IP: 54.236.1.11
[25-May-2023 07:46:39 Europe/London] API call made for IP: 54.236.1.11 with score: 63
[25-May-2023 07:46:39 Europe/London] IP 54.236.1.11 blocked from API call
the third
[25-May-2023 07:46:43 Europe/London] Checking cache for IP: 54.236.1.11
[25-May-2023 07:46:44 Europe/London] API call made for IP: 54.236.1.11 with score: 63
[25-May-2023 07:46:44 Europe/London] IP 54.236.1.11 blocked from API call
So it would seem they are all the same IP address but they are looking up each time if I'm not mistaken.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
webchills
Instead of adding a new notifier (NOTIFY_HEADER_START) in includes/templates/YOUR_TEMPLATE/common/tpl_header.php you could also use the existing notifier NOTIFY_HTML_HEAD_START in includes/templates/YOUR_TEMPLATE/common/html_header.php and change in the observer class from NOTIFY_HEADER_START to NOTIFY_HTML_HEAD_START.
This way there is no change of existing core files required when installing the plugin.
Just changed the observer as mentioned here & removed my code from index.php - it does indeed work, blocking works & it also avoids the headers already sent issue I received before. Great observation. Now I just need to solve this caching issue as I'm about to run out of API calls for another day thanks to the same IP's
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
johnjlarge
I'm not sure if the caching is working correctly. I've woken up just now & almost exhausted my API limit for the day at 7:47am
I just enabled debug mode to check the logs & it would seem it's making a fresh call even for the same ip.
From the bottom of the first debug log
[25-May-2023 07:46:22 Europe/London] Checking cache for IP: 54.236.1.11
[25-May-2023 07:46:22 Europe/London] API call made for IP: 54.236.1.11 with score: 63
[25-May-2023 07:46:22 Europe/London] IP 54.236.1.11 blocked from API call
and then the second
[25-May-2023 07:46:39 Europe/London] Checking cache for IP: 54.236.1.11
[25-May-2023 07:46:39 Europe/London] API call made for IP: 54.236.1.11 with score: 63
[25-May-2023 07:46:39 Europe/London] IP 54.236.1.11 blocked from API call
the third
[25-May-2023 07:46:43 Europe/London] Checking cache for IP: 54.236.1.11
[25-May-2023 07:46:44 Europe/London] API call made for IP: 54.236.1.11 with score: 63
[25-May-2023 07:46:44 Europe/London] IP 54.236.1.11 blocked from API call
So it would seem they are all the same IP address, but they are looking up each time if I'm not mistaken.
Just another observation on this, could it be that known spiders are prevented from creating a session, so the IP isn't cached in the session cache? I could be way off, but my initial investigation is that this IP is pinterestbot which I have as a robot in my zen cart who's online/admin robot definitions.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
johnjlarge
Just another observation on this, could it be that known spiders are prevented from creating a session, so the IP isn't cached in the session cache? I could be way off, but my initial investigation is that this IP is pinterestbot which I have as a robot in my zen cart who's online/admin robot definitions.
Known spiders are definitively prevented from creating sessions
As you are not using the page_not_found redirect, you could change in the observer class from
Code:
// Do not execute the check for the 'page_not_found' page
if ($current_page_base == 'page_not_found') {
return;
}
to
Code:
// Do not execute the check for known spiders
if (isset($spider_flag) && $spider_flag === true) {
return;
}
to disable the whole thing for known spiders
I'm not using this on a live site at the moment so cannot really test if its working
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
webchills
Known spiders are definitively prevented from creating sessions
As you are not using the page_not_found redirect, you could change in the observer class from
Code:
// Do not execute the check for the 'page_not_found' page
if ($current_page_base == 'page_not_found') {
return;
}
to
Code:
// Do not execute the check for known spiders
if (isset($spider_flag) && $spider_flag === true) {
return;
}
to disable the whole thing for known spiders
I'm not using this on a live site at the moment so cannot really test if its working
I've changed the code as suggested, but I'll have to wait until tomorrow when my api quota resets to see if it works for spiders. If it works that is quite an elegant fix as I manually block bad bot useragents via .htaccess before they load anything from my site.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
webchills
Known spiders are definitively prevented from creating sessions
As you are not using the page_not_found redirect, you could change in the observer class from
Code:
// Do not execute the check for the 'page_not_found' page
if ($current_page_base == 'page_not_found') {
return;
}
to
Code:
// Do not execute the check for known spiders
if (isset($spider_flag) && $spider_flag === true) {
return;
}
to disable the whole thing for known spiders
I'm not using this on a live site at the moment so cannot really test if its working
Great solution this modification in the code introduces an additional check to prevent unnecessary IP abuse checks.
If the current page is a 'page_not_found', the IP abuse check will be skipped.
If the visitor is a known web spider or bot, the IP abuse check will also be skipped.
This reduces unnecessary API calls to AbuseIPDB when traffic comes from known web spiders or bots, which are usually harmless.
PHP Code:
// Do not execute the check for the 'page_not_found' page or for known spiders
if ($current_page_base == 'page_not_found' || (isset($spider_flag) && $spider_flag === true)) {
return;
}
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
marcopolo
Great solution this modification in the code introduces an additional check to prevent unnecessary IP abuse checks.
If the current page is a 'page_not_found', the IP abuse check will be skipped.
If the visitor is a known web spider or bot, the IP abuse check will also be skipped.
This reduces unnecessary API calls to AbuseIPDB when traffic comes from known web spiders or bots, which are usually harmless.
PHP Code:
// Do not execute the check for the 'page_not_found' page or for known spiders
if ($current_page_base == 'page_not_found' || (isset($spider_flag) && $spider_flag === true)) {
return;
}
I've changed the modification to this to exclude spiders & 404. Just have to wait until tomorrow to check if block caching is now fully working, but on test mode all seems well. This mod seems to be evolving quickly, but it will do wonders to keep the worst offenders away & reduce my manual blocking workload massively.
Thank you all.
-
Re: AbuseIPDB Integration module
Also, as an aside in case anyone else wants to include an error message on their block page, I'm still serving a 403 but now echoing a browser message as follows.
Code:
header('HTTP/1.0 403 Forbidden');
echo 'You are forbidden! Your IP Address is marked as malicious in the abuseipdb.com database';
zen_exit();
-
Re: AbuseIPDB Integration module
Any chance we can get a github link to avoid having to add, delete, rinse, repeat?
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
dbltoe
Any chance we can get a github link to avoid having to add, delete, rinse, repeat?
Here is the GitHub link: https://github.com/CcMarc/AbuseIPDB.git
-
Re: AbuseIPDB Integration module
I Updated to the latest commit from github, which was made three hours ago, as the API results caching wasn't working on mine. My API calls reset at midnight and by 7am GMT I had hit 3.5k API calls. Checking the calls log, there were multiples for the same IP. The latest commit, saving sessions to database appears to have fixed this. Good work :)
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
johnjlarge
I Updated to the latest commit from github, which was made three hours ago, as the API results caching wasn't working on mine. My API calls reset at midnight and by 7am GMT I had hit 3.5k API calls. Checking the calls log, there were multiples for the same IP. The latest commit, saving sessions to database appears to have fixed this. Good work :)
Are you on v2.0? Switched from session caching to database caching for improved performance and reliability.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
marcopolo
Are you on v2.0? Switched from session caching to database caching for improved performance and reliability.
Yes, I'm on version 2.0 and fully up to date as of just a moment ago with the changes on github.
A couple of ideas, in the abuseipdb_api_call_2023_05.log the IPs of spiders which appear in spiders.txt are still showing as blocked, for example
2023-05-26 16:51:52 IP address 54.236.1.11 API call. Score: 63
(this is pinterest bot, which is still allowed to browse the site, but perhaps we could avoid adding and spider sessions to the api log)
Also, maybe beyond the scope of this plugin, but perhaps we could stop blocked IPs from showing in whos online?
Blocking is working really well, just thinking how the plugin could evolve. Perhaps even excluding anything in spiders.txt for even doing an api call, so it never shows in logs & doesn't use up any api hits?
I run a relatively busy & established site with over 8000 products which has been running on zen cart since 2005, so I have a lot of traffic to test this out. So far today, most normal users have scored a 0 which is as expected, but the block log has blocked a fair few really malicious IPs today, so this plugin could prove invaluable for protecting sites from the worst offenders.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
johnjlarge
Yes, I'm on version 2.0 and fully up to date as of just a moment ago with the changes on github.
A couple of ideas, in the abuseipdb_api_call_2023_05.log the IPs of spiders which appear in spiders.txt are still showing as blocked, for example
2023-05-26 16:51:52 IP address 54.236.1.11 API call. Score: 63
(this is pinterest bot, which is still allowed to browse the site, but perhaps we could avoid adding and spider sessions to the api log)
Also, maybe beyond the scope of this plugin, but perhaps we could stop blocked IPs from showing in whos online?
Blocking is working really well, just thinking how the plugin could evolve. Perhaps even excluding anything in spiders.txt for even doing an api call, so it never shows in logs & doesn't use up any api hits?
I run a relatively busy & established site with over 8000 products which has been running on zen cart since 2005, so I have a lot of traffic to test this out. So far today, most normal users have scored a 0 which is as expected, but the block log has blocked a fair few really malicious IPs today, so this plugin could prove invaluable for protecting sites from the worst offenders.
The latest v2.0.4 release of the AbuseIPDB module is now live on GitHub. This update introduces a new feature that allows you to enable or disable known spiders from bypassing IP checks. Additionally, in the previous v2.0.3 release, I added an IP Cleanup feature that automatically deletes expired IP records. You can enable or disable this functionality and configure the IP record expiration period in the admin settings.
-
Re: AbuseIPDB Integration module
I'm facing an issue with the spider detection code. The purpose of this code is to detect spiders/crawlers, if enabled will bypass the api call and creates a log log if enabled as well. However, I've noticed that the log file is not being created even though I can see spiders accessing my site.
I suspect there might be an issue with the spider detection logic or the file logging process. I would greatly appreciate it if someone with more knowledge and experience could take a look at the code snippet and help me identify the problem.
PHP Code:
// Skip API call for known spiders if enabled
if (isset($spider_flag) && $spider_flag === true && $spider_allow == 'true') {
// Check if logging is enabled for allowed spiders
$log_file_name_spiders = 'abuseipdb_spiders_' . date('Y_m') . '.log';
$log_file_path_spiders = $log_file_path . $log_file_name_spiders;
$log_message = date('Y-m-d H:i:s') . ' IP address ' . $ip . ' Spider - Score: ' . $abuseScore . PHP_EOL;
if ($spider_log_enabled == 'true') {
file_put_contents($log_file_path_spiders, $log_message, FILE_APPEND);
}
return 0; // Return 0 score for spiders or whatever default value you want
}
I have already verified that the variables ($spider_flag, $spider_allow, $spider_log_enabled, etc.) are correctly set and the paths for the log files are valid.
Could someone please review the code and provide insights into why the log file is not being created? Any suggestions, improvements, or alternative approaches to spider detection in Zen Cart are also welcome.
Thank you in advance for your assistance!
-
Re: AbuseIPDB Integration module
Being lazy and not downloading the plugin, if $log_file_path is set to DIR_FS_LOGS, then the $log_file_name_spiders should have a leading '/' since DIR_FS_LOGS doesn't end in that character.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
lat9
Being lazy and not downloading the plugin, if $log_file_path is set to DIR_FS_LOGS, then the $log_file_name_spiders should have a leading '/' since DIR_FS_LOGS doesn't end in that character.
That is not the issue, the module creates a few different logs which are all working fine. It is just this spider detection one not being created. The log file setting is set within the admin setting of the module, like so for my install: log/
Here is the admin setting:
('Log File Path', 'ABUSEIPDB_LOG_FILE_PATH', 'logs/', 'The path to the directory where log files are stored.', $cgi, now(), 45, NULL, NULL),
-
Re: AbuseIPDB Integration module
The code currently will run that section of code (logging the spider detection) only when the ABUSEIPDB_SPIDER_ALLOW setting's value is true and allow spiders to continue with the checks when false; was that the intent?
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
lat9
The code currently will run that section of code (logging the spider detection) only when the ABUSEIPDB_SPIDER_ALLOW setting's value is true and allow spiders to continue with the checks when false; was that the intent?
Yes that is the intent, if you allow spiders then this will allow you to avoid an api call check for them, if you do not allow them then the module checks their ip like any other users ip for an abuse score and will allow or block them based on your set threshold.
-
Re: AbuseIPDB Integration module
For testing purposes, I've hardcoded my IP address ('xxx.xxx.xxx.xxx') and manually set $spider_flag to true. The intention is to simulate a scenario where a known spider accesses the website.
Here's the relevant code snippet:
PHP Code:
// Hardcoding the IP for testing
$ip = 'xxx.xxx.xxx.xxx';
$spider_flag = ($ip == 'xxx.xxx.xxx.xxx') ? true : $spider_flag; // Set $spider_flag to true if the IP is xxx.xxx.xxx.xxx
// Skip API call for known spiders if enabled
if (isset($spider_flag) && $spider_flag === true && $spider_allow == 'true') {
// Check if logging is enabled for allowed spiders
$log_file_name_spiders = 'abuseipdb_spiders_' . date('Y_m') . '.log';
$log_file_path_spiders = $log_file_path . $log_file_name_spiders;
$log_message = date('Y-m-d H:i:s') . ' IP address ' . $ip . ' is identified as a Spider. AbuseIPDB API check was bypassed.' . PHP_EOL;
if ($spider_log_enabled == 'true') {
file_put_contents($log_file_path_spiders, $log_message, FILE_APPEND);
}
return 0; // Return 0 score for spiders or whatever default value you want
}
The test setup, wherein I've hardcoded my IP and set $spider_flag to true, results in successful logging - a log file gets created as expected. This suggests that the issue is unlikely with the logging mechanism itself.
Moreover, while monitoring the 'Who is Online' section, I've noticed several spiders accessing the site. However, the corresponding spider log file has not been created, leading me to believe that the spider detection part of the code is not working as expected.
To summarize, while my test setup with hardcoded values demonstrates that the logging functionality is intact, it appears that under normal site operation, spiders are not being correctly detected and logged.
It brings us to an interesting dilemma. If 'Who is Online' is accurately identifying spiders, then it appears that my spider detection code is not functioning correctly. However, if my code is working properly and there haven't been any spider visits that Zen Cart would identify as spiders, then 'Who is Online' might be giving false positives. Either way, there seems to be a discrepancy that warrants further investigation.
I'd appreciate any insights or suggestions on this matter.
-
Re: AbuseIPDB Integration module
This may be an alternative way detect spiders:
PHP Code:
// Skip API call for known spiders if enabled
$user_agent = $_SERVER['HTTP_USER_AGENT'];
$spiders_file = DIR_WS_INCLUDES . 'spiders.txt';
$spiders = file($spiders_file, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);
foreach ($spiders as $spider) {
if (strpos($user_agent, $spider) !== false) {
$spider_flag = true;
break;
}
}
if ($spider_flag && $spider_allow == 'true') {
// Check if logging is enabled for allowed spiders
$log_file_name_spiders = 'abuseipdb_spiders_' . date('Y_m') . '.log';
$log_file_path_spiders = $log_file_path . $log_file_name_spiders;
$log_message = date('Y-m-d H:i:s') . ' IP address ' . $ip . ' is identified as a Spider. AbuseIPDB API check was bypassed.' . PHP_EOL;
if ($spider_log_enabled == 'true') {
file_put_contents($log_file_path_spiders, $log_message, FILE_APPEND);
}
return 0; // Return 0 score for spiders or whatever default value you want
}
-
Re: AbuseIPDB Integration module
Noting that the $spider_flag is set IFF SESSION_FORCE_COOKIE_USE != 'True' and SESSION_BLOCK_SPIDERS == 'True' (from the zc158 /includes/init_includes/init_sessions.php lines 70-84).
Don't know if that helps ...
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
lat9
Noting that the $spider_flag is set IFF SESSION_FORCE_COOKIE_USE != 'True' and SESSION_BLOCK_SPIDERS == 'True' (from the zc158 /includes/init_includes/init_sessions.php lines 70-84).
Don't know if that helps ...
I stumbled on that during my debugging and my settings are inline with that:
Based on my settings (SESSION_FORCE_COOKIE_USE = false and SESSION_BLOCK_SPIDERS = true), the spider detection code should work as intended, but it is not.
-
Re: AbuseIPDB Integration module
I have been testing the spider detection functionality in Zen Cart to recognize my user agent string as a spider. However, I'm experiencing unexpected behavior and the spider detection does not seem to be working as intended.
Steps taken:
Modified the spiders.txt file to include the necessary entry for the user agent string I want to identify as a spider. in my case my user agent is:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
so I added: gecko to the spiders.txt
Added debug logging statements in the code to check the values of the spider blocking flag and spider flag variables.
PHP Code:
// Log the spider flag value for debugging
if (defined('SESSION_BLOCK_SPIDERS')) {
error_log('AbuseIPDB Check - Spider Blocking Enabled: ' . (SESSION_BLOCK_SPIDERS ? 'true' : 'false'));
} else {
error_log('AbuseIPDB Check - Spider Blocking status is not defined.');
}
if (isset($spider_flag)) {
error_log('AbuseIPDB Check - Spider Flag: ' . ($spider_flag ? 'true' : 'false'));
} else {
error_log('AbuseIPDB Check - Spider Flag is not set.');
}
Expected the debug logs to be created and indicate that the spider blocking flag is enabled and the spider flag is set to true.
However, the debug logs were NOT created when the user agent string matched the entry in spiders.txt, but they were created when I removed the entry.
Possible considerations:
Is there additional logic or conditions in the spider detection mechanism that I might be missing?
Are there other files or functions involved in the spider detection process that I should review?
Could there be any conflicting factors or checks affecting the spider detection outcome?
I kindly request the assistance of the Zen Cart community in understanding and resolving this issue. Any insights, suggestions, or guidance would be greatly appreciated.
Thank you for your time and assistance.
-
Re: AbuseIPDB Integration module
Just a thought.
Could it be that the spiders detection/do not allow sessions for spiders code happens further down in the code stack, so the abuseipdb plugin does its api lookup/redirect before the useragent is detected as a spider from the spiders.txt file?
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
johnjlarge
Just a thought.
Could it be that the spiders detection/do not allow sessions for spiders code happens further down in the code stack, so the abuseipdb plugin does its api lookup/redirect before the useragent is detected as a spider from the spiders.txt file?
I checked that I think it's good from the program flow I referenced:
https://docs.zen-cart.com/dev/code/program_flow/
Set up and start session if valid session is above where this module comes in which is: NOTIFY_HTML_HEAD_START (the /includes/templates/common/html_header.php) unless I'm missing something. I tried going further down the list which did not resolve the issue.
-
Re: AbuseIPDB Integration module
Recap and Solution I Implemented in v2.0.7 for the Meantime:
Problem:
During testing, I faced difficulties with the spider detection feature in Zen Cart. Specifically, the utilization of the $spider_flag variable did not produce the expected results, particularly in generating logs after detecting a spider using:
PHP Code:
if (isset($spider_flag) && $spider_flag === true)
Solution Implemented:
To resolve this issue, I decided to clone the spider detection code from Zen Cart and integrate it directly into the module functions file. This allowed me to incorporate the spider detection functionality without relying on Zen Cart's $spider_flag variable. As a result, the spider detection now works as intended within my custom code.
PHP Code:
function checkSpiderFlag() {
if (defined('SESSION_BLOCK_SPIDERS')) {
$user_agent_abuseipdb = '';
if (isset($_SERVER['HTTP_USER_AGENT'])) {
$user_agent_abuseipdb = strtolower($_SERVER['HTTP_USER_AGENT']);
}
$spider_flag_abuseipdb = false;
if (!empty($user_agent_abuseipdb)) {
$spiders_abuseipdb = file(DIR_WS_INCLUDES . 'spiders.txt');
for ($i = 0, $n = sizeof($spiders_abuseipdb); $i < $n; $i++) {
if (!empty($spiders_abuseipdb[$i]) && substr($spiders_abuseipdb[$i], 0, 4) != '$Id:') {
if (is_integer(strpos($user_agent_abuseipdb, trim($spiders_abuseipdb[$i])))) {
$spider_flag_abuseipdb = true;
break;
}
}
}
}
return $spider_flag_abuseipdb;
}
return false;
Although the current solution successfully resolves the logging problem, I am interested in understanding why using the original $spider_flag variable did not produce the expected outcome. If anyone has any insights, suggestions, or guidance that could be a potential resolution that would allow me to revert back to using the $spider_flag in the future, please do let me know!
Thank you for your time and assistance.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
marcopolo
Recap and Solution I Implemented in v2.0.7 for the Meantime:
Problem:
During testing, I faced difficulties with the spider detection feature in Zen Cart. Specifically, the utilization of the $spider_flag variable did not produce the expected results, particularly in generating logs after detecting a spider using:
PHP Code:
if (isset($spider_flag) && $spider_flag === true)
Solution Implemented:
To resolve this issue, I decided to clone the spider detection code from Zen Cart and integrate it directly into the module functions file. This allowed me to incorporate the spider detection functionality without relying on Zen Cart's $spider_flag variable. As a result, the spider detection now works as intended within my custom code.
PHP Code:
function checkSpiderFlag() {
if (defined('SESSION_BLOCK_SPIDERS')) {
$user_agent_abuseipdb = '';
if (isset($_SERVER['HTTP_USER_AGENT'])) {
$user_agent_abuseipdb = strtolower($_SERVER['HTTP_USER_AGENT']);
}
$spider_flag_abuseipdb = false;
if (!empty($user_agent_abuseipdb)) {
$spiders_abuseipdb = file(DIR_WS_INCLUDES . 'spiders.txt');
for ($i = 0, $n = sizeof($spiders_abuseipdb); $i < $n; $i++) {
if (!empty($spiders_abuseipdb[$i]) && substr($spiders_abuseipdb[$i], 0, 4) != '$Id:') {
if (is_integer(strpos($user_agent_abuseipdb, trim($spiders_abuseipdb[$i])))) {
$spider_flag_abuseipdb = true;
break;
}
}
}
}
return $spider_flag_abuseipdb;
}
return false;
Although the current solution successfully resolves the logging problem, I am interested in understanding why using the original $spider_flag variable did not produce the expected outcome. If anyone has any insights, suggestions, or guidance that could be a potential resolution that would allow me to revert back to using the $spider_flag in the future, please do let me know!
Thank you for your time and assistance.
Testing here, and it's working really well with the new spiders detection code. Saving a lot of API calls on my site. Also, I've set my threshold at 30% as most of my customers score a 0 threat score, so I'm currently blocking about 10% of hits to the server. I've gone through the logs manually checking bad IPs and there are some real nasty ones in there. This plugin will save a lot of server resources and turn away some of the worst bad bots & crawlers. Invaluable to small shop owners.
Thank you for all the hard work :)
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
johnjlarge
Testing here, and it's working really well with the new spiders detection code. Saving a lot of API calls on my site. Also, I've set my threshold at 30% as most of my customers score a 0 threat score, so I'm currently blocking about 10% of hits to the server. I've gone through the logs manually checking bad IPs and there are some real nasty ones in there. This plugin will save a lot of server resources and turn away some of the worst bad bots & crawlers. Invaluable to small shop owners.
Thank you for all the hard work :)
having recently implemented this plugin on a couple of sites, i can truly see its benefit.
it is a GREAT addition to the zen-cart plugin repository.
thanks to @marcopolo for this contribution!
-
Re: AbuseIPDB Integration module
Heya Marco,
I just submitted a PR/Merge request to your Github repository for adding the Contributor Badge onto the admin dashboard to get a higher API daily limits. The changes aren't that serious, but I added a bit to the documentation and upped the version number. I have also submitted, what would now be, 2.1.2 to the ZC Plugins database.
You can view my PR here:
https://github.com/CcMarc/AbuseIPDB/pull/6
-
1 Attachment(s)
Re: AbuseIPDB Integration module
Someone on GitHub requested a whos_online feature. I use an enhanced version of whos_online and am currently still on Zen Cart 1.5.5, so I'm not sure about compatibility with newer versions. However, if you'd like to try it, this enhanced version adds the following features directly within the whos_online screen:
- Exclude IPs by AbuseIPDB Threshold: Automatically filter out IPs from the "Who's Online" list based on their AbuseIPDB score exceeding a set threshold.
- Display AbuseIPDB Score: Show the AbuseIPDB score next to each IP address in the "Who's Online" list, indicating the level of potential abuse associated with the IP.
- Shield Icon for Blocked IPs: Display a shield icon for IPs automatically blocked by the module, indicating they have met or exceeded the threshold.
- Ban Icon for Manual Blacklisting: Provide a ban icon that allows administrators to manually blacklist an IP address, adding it to the blacklist file directly from the "Who's Online" interface.
Attachment 20737
-
1 Attachment(s)
Re: AbuseIPDB Integration module
Here's the complete enhanced_whos_online_2.0 plugin with my modifications. There are some image files that go along with the original plugin, in case you're not currently using it and need those:
Attachment 20738
-
Re: AbuseIPDB Integration module
This is a great plugin. It has certainly reduced the time normally required blocking the script-kiddies.
AbuseIPDB v2.1.2; zc 158a and 2.1.0; PHP 8.3
In admin > ABUSEIPDB Configuration > Redirect URL Option 2
Code:
Option 2: 403 Forbidden - If selected, the user will be shown a 403 Forbidden error
message if their IP is found to be abusive. This option provides a more explicit message indicating that the user is forbidden from accessing
the website due to their IP being flagged as abusive.
How can I provide a more explicit message?
The current message is:
Quote:
Access to xxx.xxx.xxx.xxx was denied.
You don't have authorisation to view this page.
-
Re: AbuseIPDB Integration module
Using the Developer's Tool Kit, you could search for
You don't have authorisation
Then change the file.
-
1 Attachment(s)
Re: AbuseIPDB Integration module
Running ZC 2.1.0
Installed Access Blocker. Struggled to get email verification to work. Ended up using a different email address which then worked. (strange) Anyway, now I'm going over the settings in ZenCart Admin and noticed. (see attached) Basically it wants a user id number from the URL at AbuseIPDB which no longer displays a user ID in the URL. So this seems to be outdated and needs correction or deletion. Or the instructions updated to be useful in finding this information for the field.
-
Re: AbuseIPDB Integration module
Access Blocker and AbuseIPDB are totally different plugins.
Access Blocker uses the ipdata.co site and you need an account from that site for your "ipData Service: API Key" .
AbuseIPDB uses the AbuseIPDB.com site and you need an account from that site for your "AbuseIPDB: API Key"
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
lynbor
Running ZC 2.1.0
Installed Access Blocker. Struggled to get email verification to work. Ended up using a different email address which then worked. (strange) Anyway, now I'm going over the settings in ZenCart Admin and noticed. (see attached) Basically it wants a user id number from the URL at AbuseIPDB which no longer displays a user ID in the URL. So this seems to be outdated and needs correction or deletion. Or the instructions updated to be useful in finding this information for the field.
As the person who wrote that in for AbuseIPDB, the instructions are fine and is relative to the AbuseIPDB site. When you click on the View link here:
https://www.zen-cart.com/image/png;b...BJRU5ErkJggg==
https://i.imgur.com/E8k1vy6.png
You will find your AbuseIPDB userID number which is what that prompt is asking for.
Which site did you sign up for and which module did you install? It sounds like you signed up for one site and then you installed the other.
You may want the Access Blocker Support thread: https://www.zen-cart.com/showthread....Support-Thread
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
lynbor
Running ZC 2.1.0
Installed Access Blocker. Struggled to get email verification to work. Ended up using a different email address which then worked. (strange) Anyway, now I'm going over the settings in ZenCart Admin and noticed. (see attached) Basically it wants a user id number from the URL at AbuseIPDB which no longer displays a user ID in the URL. So this seems to be outdated and needs correction or deletion. Or the instructions updated to be useful in finding this information for the field.
Looking at your response in the Access Blocker thread... Okay. Which site did you complete the registration for the account on?
-
Re: AbuseIPDB Integration module
@everyone
Just for interest - which treshold score do you have set?
I'm at 40 now
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
Shop Suey
@everyone
Just for interest - which treshold score do you have set?
I'm at 40 now
I'm at threshold of 45 but I also use Access Blocker which often catches script kiddies who have the same messages but change IP addresses.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
retched
Looking at your response in the Access Blocker thread... Okay. Which site did you complete the registration for the account on?
I initially posted in the wrong support thread. AbuseIPDB is what I installed and used its links for getting the API.
And the "Public View" gives the same results, no ID number in the URL as the setting page in ZenCart that I included a screen shot of gives examples of. Thinking maybe a browser add-on or setting might be masking the number I tried using a different browser to access my account at AbuseIPDB but no difference. The URL simply shows "webdomain/account" nothing more as far as an ID number.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
lynbor
I initially posted in the wrong support thread. AbuseIPDB is what I installed and used its links for getting the API.
And the "Public View" gives the same results, no ID number in the URL as the setting page in ZenCart that I included a screen shot of gives examples of. Thinking maybe a browser add-on or setting might be masking the number I tried using a different browser to access my account at AbuseIPDB but no difference. The URL simply shows "webdomain/account" nothing more as far as an ID number.
I have no idea you're not getting the ID because I can click the View and see my URL as "https://www.abuseipdb.com/user/139879". Let's try this.
Do you see the option for "Contributor Badge"? If you have that, click on that tab in your User Account Summary area after logging in. There should be a HTML Markup window in that area. You should see an img src tag that looks like this (for me) :
Code:
<a href="https://www.abuseipdb.com/user/139879" title="AbuseIPDB is an IP address blacklist for webmasters and sysadmins to report IP addresses engaging in abusive behavior on their networks">
<img src="https://www.abuseipdb.com/contributor/139879.svg" alt="AbuseIPDB Contributor Badge" style="width: 401px;">
</a>
From that block the numbers next to "user/" and "contributor/" should be your user ID. If you don't see that... something was not verified and you're not getting an ID because you did not verify either your account or ownership of your domain.
It should also be said that this portion is 100% OPTIONAL. It's only there to boost your ability to report to about 5000 and flag your account as Webmaster and Supporter. You only need "Webmaster" to get API access I believe.
-
Re: AbuseIPDB Integration module
Do you have entered the "AbuseIPDB - User ID" ?
I can't find it at their website.
-
Re: AbuseIPDB Integration module
I see at the logs that an IP has been abandoned via API.
Then ~6 hours later this IP shows up again and is again? blacklisted via API (as the logs suggest).
Is it possible to test so if I would use this bad IP?
The test mode seems to do something different.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
Shop Suey
Do you have entered the "AbuseIPDB - User ID" ?
I can't find it at their website.
No. You don't need to use the AbuseIPDB-User ID. This is only if you want the Abuse IPDB Contributor Badge to appear in your backend to grant you the Webmaster+Supporter status so that you can check and report on 5000 IPs a day instead of 1000 IPs a day.
In order for the module to work however, you need to input the API Key from the API section.
Also please read my last response with regards to Contributor Badge. That is another way to see your Profile ID.
-
Re: AbuseIPDB Integration module
Thank you.
I just wasn't sure how to deal with it.
And today there's no id I could extract of the url as said in the settings of my version (even if I wanted to do so).
Maybe they have changed that?!
-
Re: AbuseIPDB Integration module
I'm going to create a new account because I'm not seeing how the User ID isn't viewable in the URL bar. I might have opted into something and not realize it.
EDIT: That was hella fast. Made a new account as a webmaster AND individual. I can click on the "View" link and see the URL to the new profiles and have the Contributor Badge tab too. (Didn't need to verify either one. Just made it and on the dashboard, I'm provided a link to the profile (the view link) and I can see it in the next page.)
What am I seeing that anyone else on this thread isn't as far as how to get your profile ID?
-
Re: AbuseIPDB Integration module
For the sake of example:
After clicking on the View Profile link on the main AbuseIPDB dashboard just as you load in (of an unverified account I just made). I see the following:
https://i.imgur.com/KksVcCP.png
That number at the end of the URL bar is the profile ID number to be inserted into the admin dashboard where prompted. Is no one else seeing this when you log in or am I overcomplicating things?
-
1 Attachment(s)
Re: AbuseIPDB Integration module
I can falsify that.
I have just a clean basic url or any subfolders e.g. /report/ or /bulk-report/ and so on.
But no url paramaters.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
Shop Suey
I can falsify that.
I have just a clean basic url or any subfolders e.g. /report/ or /bulk-report/ and so on.
But no url paramaters.
Where are you looking exactly? Like what does your member area of the AbuseIPDB website look like just after you log in?
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
Shop Suey
I can falsify that.
I have just a clean basic url or any subfolders e.g. /report/ or /bulk-report/ and so on.
But no url paramaters.
Can you visit the member area. The top right hand corner, click Account. And there should be a box that has a link to "View Profile". What you showed is the main abuseipdb.com when you visit. After you log in, you're taken immediately to the dashboard/account area.
-
1 Attachment(s)
Re: AbuseIPDB Integration module
In my case this is the "account" triggered page. On right top dropdown trigger there would just else be the "logout" link.
And at this page is no "view profile" string.
BTW: my profile is set to "private". That shouldn't be relevant but just for completeness.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
Shop Suey
In my case this is the "account" triggered page. On right top dropdown trigger there would just else be the "logout" link.
And at this page is no "view profile" string.
BTW: my profile is set to "private". That shouldn't be relevant but just for completeness.
AHA Okay! When the profile is privated, it doesn't show you the view link.
Very well. Visit the Contributor Badge and follow what I said here:
https://www.zen-cart.com/showthread....52#post1405052
The other option would be temporarily make it viewable... click the link, get the ID, input the ID, then toggle your profile private again. I guess I have to change the help text.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
retched
AHA Okay! When the profile is privated, it doesn't show you the view link.
Very well. Visit the Contributor Badge and follow what I said here:
https://www.zen-cart.com/showthread....52#post1405052
The other option would be temporarily make it viewable... click the link, get the ID, input the ID, then toggle your profile private again. I guess I have to change the help text.
Thank you very much.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
retched
I have no idea you're not getting the ID because I can click the View and see my URL as "https://www.abuseipdb.com/user/139879". Let's try this.
Do you see the option for "Contributor Badge"? If you have that, click on that tab in your User Account Summary area after logging in. There should be a HTML Markup window in that area. You should see an img src tag that looks like this (for me) :
Code:
<a href="https://www.abuseipdb.com/user/139879" title="AbuseIPDB is an IP address blacklist for webmasters and sysadmins to report IP addresses engaging in abusive behavior on their networks">
<img src="https://www.abuseipdb.com/contributor/139879.svg" alt="AbuseIPDB Contributor Badge" style="width: 401px;">
</a>
From that block the numbers next to "user/" and "contributor/" should be your user ID. If you don't see that... something was not verified and you're not getting an ID because you did not verify either your account or ownership of your domain.
It should also be said that this portion is 100% OPTIONAL. It's only there to boost your ability to report to about 5000 and flag your account as Webmaster and Supporter. You only need "Webmaster" to get API access I believe.
Perhaps it was the holidays or maybe my account just need to be "approved" but I looked again today after returning from vacation and viola it is showing in the "Public View" URL as indicated by a previous message in this thread. Whew... All is good and I'm seeing stats and such so I'm all fixed for now. Thanks to everyone for putting up with me here. Cheers! And may you all have a very good 2025.
-
Re: AbuseIPDB Integration module
AbuseIPDB v3.0.0 is now available for download: https://github.com/CcMarc/AbuseIPDB/...PDB.v3.0.0.zip
This version is released as a Zen Cart encapsulated plugin, supporting Zen Cart versions 2.1.0 and later.
-
Re: AbuseIPDB Integration module
-
Re: AbuseIPDB Integration module
🛡️ Major Release – AbuseIPDB v4.0.0
This version introduces advanced flood detection and blocking, giving you full control over how your site handles aggressive traffic patterns.
🚨 What’s New:
Flood Blocking by IP Range
You can now automatically block 2-octet (e.g., 192.168.*) or 3-octet (e.g., 192.168.1.*) IP ranges.
Example: If 192.168.x.x exceeds the request limit (default 25 hits in 30 minutes), the entire 2-octet range will be blocked. If 30 minutes pass with no further hits, the block resets.
Country & Foreign Blocking
Works the same way — if traffic from a country exceeds the flood threshold, the country is temporarily blocked.
You can choose to allow low-score IPs through by setting a minimum AbuseIPDB score (or set it to 0 to block all traffic from that country).
Manual country blocking is also supported.
High Score Caching
New AbuseIPDB high-score cache prevents repeated API calls. If an IP already scored above the block threshold, it won’t be rechecked for X days (default: 7).
New Visual Shields in Who’s Online
Clearly see why an IP is being blocked:
🔴 Red – Score-blocked by AbuseIPDB
🟣 Purple – Manually blacklisted
🔵 Blue – Manually country-blocked
🟠 Orange – Flood-blocked (range, country, or foreign)
Personal Recommendation:
For daily use, I recommend enabling only the 2-octet, 3-octet, and foreign flood protection.
Use country-based blocking only during an active attack — because it will also block IPs from your default country.
That’s why foreign blocking is preferred for general use — it works the same way but will never block your default country.
Enjoy!
-
Re: AbuseIPDB Integration module
Installed and did cleanup. 500 error with this debug
Code:
[17-May-2025 14:26:37 America/Chicago] PHP Fatal error: Uncaught Error: Undefined constant "ABUSEIPDB_HIGH_SCORE_CACHE_ENABLED" in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php:222Stack trace:
#0 /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php(22): abuseipdb_observer->checkAbusiveIP()
#1 /home/MY_USER/public_html/includes/classes/traits/NotifierManager.php(107): abuseipdb_observer->update(Object(notifier), 'NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE', NULL, NULL, NULL, NULL, NULL, NULL, NULL)
#2 /home/MY_USER/public_html/includes/templates/MY_TEMPLATE/common/html_header.php(19): base->notify('NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE')
#3 /home/MY_USER/public_html/index.php(48): require('/home/MY_USER/...')
#4 {main}
thrown in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php on line 222
[17-May-2025 14:26:37 America/Chicago] Request URI: /, IP address: 123.234.134.255
--> PHP Fatal error: Uncaught Error: Undefined constant "ABUSEIPDB_HIGH_SCORE_CACHE_ENABLED" in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php:222
Stack trace:
#0 /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php(22): abuseipdb_observer->checkAbusiveIP()
#1 /home/MY_USER/public_html/includes/classes/traits/NotifierManager.php(107): abuseipdb_observer->update(Object(notifier), 'NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE', NULL, NULL, NULL, NULL, NULL, NULL, NULL)
#2 /home/MY_USER/public_html/includes/templates/MY_TEMPLATE/common/html_header.php(19): base->notify('NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE')
#3 /home/MY_USER/public_html/index.php(48): require('/home/MY_USER/...')
#4 {main}
thrown in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php on line 222.
[17-May-2025 14:26:37 America/Chicago] Request URI: /, IP address: 123.234.134.255
--> PHP Fatal error: Uncaught Error: Undefined constant "ABUSEIPDB_HIGH_SCORE_CACHE_ENABLED" in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php:222
Stack trace:
#0 /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php(22): abuseipdb_observer->checkAbusiveIP()
#1 /home/MY_USER/public_html/includes/classes/traits/NotifierManager.php(107): abuseipdb_observer->update(Object(notifier), 'NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE', NULL, NULL, NULL, NULL, NULL, NULL, NULL)
#2 /home/MY_USER/public_html/includes/templates/MY_TEMPLATE/common/html_header.php(19): base->notify('NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE')
#3 /home/MY_USER/public_html/index.php(48): require('/home/MY_USER/...')
#4 {main}
thrown in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php on line 222.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
dbltoe
Installed and did cleanup. 500 error with this debug
Code:
[17-May-2025 14:26:37 America/Chicago] PHP Fatal error: Uncaught Error: Undefined constant "ABUSEIPDB_HIGH_SCORE_CACHE_ENABLED" in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php:222Stack trace:
#0 /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php(22): abuseipdb_observer->checkAbusiveIP()
#1 /home/MY_USER/public_html/includes/classes/traits/NotifierManager.php(107): abuseipdb_observer->update(Object(notifier), 'NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE', NULL, NULL, NULL, NULL, NULL, NULL, NULL)
#2 /home/MY_USER/public_html/includes/templates/MY_TEMPLATE/common/html_header.php(19): base->notify('NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE')
#3 /home/MY_USER/public_html/index.php(48): require('/home/MY_USER/...')
#4 {main}
thrown in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php on line 222
[17-May-2025 14:26:37 America/Chicago] Request URI: /, IP address: 123.234.134.255
--> PHP Fatal error: Uncaught Error: Undefined constant "ABUSEIPDB_HIGH_SCORE_CACHE_ENABLED" in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php:222
Stack trace:
#0 /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php(22): abuseipdb_observer->checkAbusiveIP()
#1 /home/MY_USER/public_html/includes/classes/traits/NotifierManager.php(107): abuseipdb_observer->update(Object(notifier), 'NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE', NULL, NULL, NULL, NULL, NULL, NULL, NULL)
#2 /home/MY_USER/public_html/includes/templates/MY_TEMPLATE/common/html_header.php(19): base->notify('NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE')
#3 /home/MY_USER/public_html/index.php(48): require('/home/MY_USER/...')
#4 {main}
thrown in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php on line 222.
[17-May-2025 14:26:37 America/Chicago] Request URI: /, IP address: 123.234.134.255
--> PHP Fatal error: Uncaught Error: Undefined constant "ABUSEIPDB_HIGH_SCORE_CACHE_ENABLED" in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php:222
Stack trace:
#0 /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php(22): abuseipdb_observer->checkAbusiveIP()
#1 /home/MY_USER/public_html/includes/classes/traits/NotifierManager.php(107): abuseipdb_observer->update(Object(notifier), 'NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE', NULL, NULL, NULL, NULL, NULL, NULL, NULL)
#2 /home/MY_USER/public_html/includes/templates/MY_TEMPLATE/common/html_header.php(19): base->notify('NOTIFY_HTML_HEA...', 'index', 'MY_TEMPLATE')
#3 /home/MY_USER/public_html/index.php(48): require('/home/MY_USER/...')
#4 {main}
thrown in /home/MY_USER/public_html/zc_plugins/AbuseIPDB/v4.0.0/catalog/includes/classes/observers/abuseipdb_observer.php on line 222.
Can you confirm the following admin setting for the module that it says: (third one down)
Total Settings 47
Also confirm you see the admin setting: Enable High Score Cache Extension
-
Re: AbuseIPDB Integration module
Can't access the admin settings with the mod disabled, but the database still shows 3.0.4 version and 27 for total settings.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
marcopolo
Let me know what module is using the file: jscript_framework.php as it is not part of this modules files, if you can upload the file here so I can take a look at the code and see what it is doing.
Put back your old files. Sounds like you did not uninstall it first. This was not upgrade you have to uninstall first then do a fresh install as noted.
-
Re: AbuseIPDB Integration module
Plugin Manager was still showing 3.0.4, did an uninstall, zc_plugins directory showed only 4.0.0 as I had done the cleanup.
Reinstalled using Plugin Manager and all is fine. Got the 47 and the Enable High Score...
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
dbltoe
Can't access the admin settings with the mod disabled, but the database still shows 3.0.4 version and 27 for total settings.
You can upload the files from 3.0.4 into 4.0.0 that should allow you to login and uninstall it.
just manually upload:
zc_plugins\AbuseIPDB\v3.0.4\*
into
zc_plugins\AbuseIPDB\v4.0.0\*
or just
zc_plugins\AbuseIPDB\v3.0.4\catalog\includes\classes\observers\abuseipdb_observe r.php
into
zc_plugins\AbuseIPDB\v4.0.0\catalog\includes\classes\observers\abuseipdb_observe r.php
that should let you back into admin.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
dbltoe
Plugin Manager was still showing 3.0.4, did an uninstall, zc_plugins directory showed only 4.0.0 as I had done the cleanup.
Reinstalled using Plugin Manager and all is fine. Got the 47 and the Enable High Score...
Ok great glad it is working!
So for others not to have this issue as noted in the readme:
Major Update Notice: If you are upgrading from v3.0.4 or earlier, you must uninstall the previous module before installing v4.0.0.
⚡ Important: Be sure to screen-capture your existing settings before uninstalling AbuseIPDB v3.0.4 or lower to preserve your configuration.
-
Re: AbuseIPDB Integration module
Please review your README.md and identify the steps from an encapsulated plugin to a newer plugin. Otherwise, others will lose their API data as we did.
I would note that, normally, a plugin notifies the owner of an update, the update is done, and the option to clean old files follows the upgrade. https://docs.zen-cart.com/dev/plugin...ins/upgrading/
-
Re: AbuseIPDB Integration module
You might want to move that message inside the INSTALLATTION AND UPGRADE section.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
dbltoe
Please review your README.md and identify the steps from an encapsulated plugin to a newer plugin. Otherwise, others will lose their API data as we did.
I would note that, normally, a plugin notifies the owner of an update, the update is done, and the option to clean old files follows the upgrade.
https://docs.zen-cart.com/dev/plugin...ins/upgrading/
As stated, the instructions are clear — you need to uninstall. I could’ve made it an upgrade, but that would’ve meant a lot more work for the installer. Unfortunately, this means you’ll lose your database data. It is possible to skip uninstalling certain tables, but that’s more of an advanced option. Since I’m offering this for free, I don’t have the time to troubleshoot those kinds of setups. This update adds a lot of new features, so it had to be done this way.
-
Re: AbuseIPDB Integration module
Posting again so everyone is clear on this:
INSTALLATION AND UPGRADE
Major Update Notice: If you are upgrading from v3.0.4 or earlier, you must uninstall the previous module before installing v4.0.0.
⚡ Important: Be sure to screen-capture your existing settings before uninstalling AbuseIPDB v3.0.4 or lower to preserve your configuration.
Advanced Uninstallation: Preserving Cache Database
If you are an advanced user and do not want to lose your cache database when uninstalling the plugin, you can modify the installer to preserve the database tables (abuseipdb_cache, abuseipdb_maintenance, and abuseipdb_flood). Follow these steps:
Open the installer file for your current version (e.g., ScriptedInstaller.php) in a text editor.
Locate the executeUninstall() method near the end of the file.
Delete the following lines to prevent dropping the tables during uninstallation:
PHP Code:
$this->executeInstallerSql("DROP TABLE IF EXISTS " . TABLE_ABUSEIPDB_CACHE);
$this->executeInstallerSql("DROP TABLE IF EXISTS " . TABLE_ABUSEIPDB_MAINTENANCE);
Save the file and proceed with the uninstallation via the Zen Cart admin panel. This will remove the plugin settings but leave the tables intact.
When you install the new version, the installer will skip creating these tables if they already exist, preserving your data.
🛡️ Major Release – AbuseIPDB v4.0.0
This version introduces advanced flood detection and blocking, giving you full control over how your site handles aggressive traffic patterns.
🚨 What’s New:
Flood Blocking by IP Range
You can now automatically block 2-octet (e.g., 192.168.*) or 3-octet (e.g., 192.168.1.*) IP ranges.
Example: If 192.168.x.x exceeds the request limit (default 25 hits in 30 minutes), the entire 2-octet range will be blocked. If 30 minutes pass with no further hits, the block resets.
Country & Foreign Blocking
Works the same way — if traffic from a country exceeds the flood threshold, the country is temporarily blocked.
You can choose to allow low-score IPs through by setting a minimum AbuseIPDB score (or set it to 0 to block all traffic from that country).
Manual country blocking is also supported.
High Score Caching
New AbuseIPDB high-score cache prevents repeated API calls. If an IP already scored above the block threshold, it won’t be rechecked for X days (default: 7).
New Visual Shields in Who’s Online
Clearly see why an IP is being blocked:
🔴 Red – Score-blocked by AbuseIPDB
🟣 Purple – Manually blacklisted
🔵 Blue – Manually country-blocked
🟠 Orange – Flood-blocked (range, country, or foreign)
Personal Recommendation:
For daily use, I recommend enabling only the 2-octet, 3-octet, and foreign flood protection.
Use country-based blocking only during an active attack — it will block IPs from your default country as well.
NOTE:
The 2-octet and 3-octet flood logic will block IPs even from your default country — there's no skip setting for those.
This is by design, as tight-range IP floods are typically bot attacks.
I may add an option to bypass default-country IPs in a future version.
Enjoy!
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
marcopolo
Posting again so everyone is clear on this:
INSTALLATION AND UPGRADE
Major Update Notice: If you are upgrading from v3.0.4 or earlier, you must uninstall the previous module before installing v4.0.0.
⚡ Important: Be sure to screen-capture your existing settings before uninstalling AbuseIPDB v3.0.4 or lower to preserve your configuration.
Advanced Uninstallation: Preserving Cache Database
If you are an advanced user and do not want to lose your
cache database when uninstalling the plugin, you can modify the installer to preserve the database tables (abuseipdb_cache, abuseipdb_maintenance, and abuseipdb_flood). Follow these steps:
Open the installer file for your current version (e.g., ScriptedInstaller.php) in a text editor.
Locate the executeUninstall() method near the end of the file.
Delete the following lines to prevent dropping the tables during uninstallation:
PHP Code:
$this->executeInstallerSql("DROP TABLE IF EXISTS " . TABLE_ABUSEIPDB_CACHE);
$this->executeInstallerSql("DROP TABLE IF EXISTS " . TABLE_ABUSEIPDB_MAINTENANCE);
Save the file and proceed with the uninstallation via the Zen Cart admin panel. This will remove the plugin settings but leave the tables intact.
When you install the new version, the installer will skip creating these tables if they already exist, preserving your data.
🛡️ Major Release – AbuseIPDB v4.0.0
This version introduces advanced flood detection and blocking, giving you full control over how your site handles aggressive traffic patterns.
🚨 What’s New:
Flood Blocking by IP Range
You can now automatically block 2-octet (e.g., 192.168.*) or 3-octet (e.g., 192.168.1.*) IP ranges.
Example: If 192.168.x.x exceeds the request limit (default 25 hits in 30 minutes), the entire 2-octet range will be blocked. If 30 minutes pass with no further hits, the block resets.
Country & Foreign Blocking
Works the same way — if traffic from a country exceeds the flood threshold, the country is temporarily blocked.
You can choose to allow low-score IPs through by setting a minimum AbuseIPDB score (or set it to 0 to block all traffic from that country).
Manual country blocking is also supported.
High Score Caching
New AbuseIPDB high-score cache prevents repeated API calls. If an IP already scored above the block threshold, it won’t be rechecked for X days (default: 7).
New Visual Shields in Who’s Online
Clearly see why an IP is being blocked:
🔴 Red – Score-blocked by AbuseIPDB
🟣 Purple – Manually blacklisted
🔵 Blue – Manually country-blocked
🟠 Orange – Flood-blocked (range, country, or foreign)
Personal Recommendation:
For daily use, I recommend enabling only the 2-octet, 3-octet, and foreign flood protection.
Use country-based blocking only during an active attack — it will block IPs from your default country as well.
NOTE:
The 2-octet and 3-octet flood logic will block IPs even from your default country — there's no skip setting for those.
This is by design, as tight-range IP floods are typically bot attacks.
I may add an option to bypass default-country IPs in a future version.
Enjoy!
Important Note:
Actually, do not keep the old tables — the new version of the plugin includes an updated abuseipdb_cache table with a new column I forgot to mention (flood_tracked).
-
Re: AbuseIPDB Integration module
Ignore the post before this one where I gave you a option to preserve your tables that will not work. The new version of the plugin includes an updated abuseipdb_cache table with a new column I forgot to mention (flood_tracked).
-
Re: AbuseIPDB Integration module
I submitted a PR on GitHub for a new installer version that should resolve most of your problems.
If you adopt it, you still have to update the install explanation in the readme...
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
dbltoe
Plugin Manager was still showing 3.0.4, did an uninstall, zc_plugins directory showed only 4.0.0 as I had done the cleanup.
Reinstalled using Plugin Manager and all is fine. Got the 47 and the Enable High Score...
New Version Available: AbuseIPDB v4.0.1
The latest version is now available on GitHub: v4.0.1
This update adds full upgrade support — you can now upgrade without uninstalling.
Special thanks to @piloujp for contributing to the improved upgrade logic.
[@swguy] — please disregard my previously submitted v4.0.0 release. I’ll be submitting v4.0.1 instead.
GitHub: https://github.com/CcMarc/AbuseIPDB
-
Re: AbuseIPDB Integration module
I installed 4.01 release over an old version without any problem. :)
I just have one question, why do you keep version number in configuration table? With encapsulated plugins, Plugin Manager saves this information in plugin_control_version table already.
-
Re: AbuseIPDB Integration module
Quote:
Originally Posted by
pilou2
I installed 4.01 release over an old version without any problem. :)
I just have one question, why do you keep version number in configuration table? With encapsulated plugins, Plugin Manager saves this information in plugin_control_version table already.
You're absolutely right — I could pull it from the plugin_control_version table. The encapsulated plugin logic is still fairly new to me, and I haven’t fully transitioned to Zen Cart v2.1.0 yet — I’m in the middle of that upgrade process. The version number in the configuration table was part of the older approach, and I just left it in place when converting the plugin to an encapsulated version.
-
Re: AbuseIPDB Integration module
I’m exploring a possible new feature for the AbuseIPDB plugin to prevent bots from rapidly creating sessions in Zen Cart (e.g., 1000+ sessions in a short time), which can overload the server. I’ve seen this happen a few times—bots create thousands of sessions and cause major performance issues. Since Zen Cart’s session_start() in application_top.php runs before the plugin can intervene, we need to block these requests before session creation.
Goal:
Block session creation for IPs that exceed a rate threshold (e.g., 100 sessions in 1 minute), while allowing normal browsing patterns (e.g., 100 sessions over 30 minutes).
Proposed Approach:
Use an auto-loader or similar method to run a check before session_start() in application_top.php.
Track session rates per IP in TABLE_ABUSEIPDB_CACHE (session count and window start time).
Use a sliding window (e.g., 60 seconds): increment count per request, reset after window expires.
If the count exceeds the threshold, return a 403 Forbidden response and exit.
Alternative (Not Preferred):
Dynamically write deny rules to .htaccess to block IPs at the Apache level before PHP runs. We’d prefer to avoid this for compatibility with non-Apache servers.
This issue is rare but impactful, so we need to address it. I’d really appreciate input from anyone who’s tackled similar problems, or ideas on the cleanest and most portable way to intercept or throttle session creation before session_start() runs. Any advice on standard mechanisms, code examples, or pitfalls to watch out for would be greatly appreciated!
If there isn’t a clean way to accomplish this in the current Zen Cart architecture, I’d suggest considering it for a future version. It would be ideal if Zen Cart provided a standard pre-session hook or filtering mechanism—either in the core or through a well-documented extension point—so modules like AbuseIPDB (or others) can intercept and block abusive requests before sessions are created. This would make handling rate-limiting and abuse much more robust and portable going forward.
Thanks,
