AbuseIPDB Integration module

[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.

// Redirect to the 404 page
            header('HTTP/1.0 403 Forbidden');
            zen_exit();

[marcopolo]

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.

// 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?

[johnjlarge]

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.

[johnjlarge]

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?

[marcopolo]

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.

[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.

[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.

[johnjlarge]

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

[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.

[webchills]

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

// Do not execute the check for the 'page_not_found' page
		if ($current_page_base == 'page_not_found') {
			return;
		}

to

// 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