IP Blocker for v1.5.x

How's about a button on the Who's Online page (per visitor) to click 'block this IP' which would add that IP to the blocked list?
Any thoughts or a proper pain in the proverbial to implement?

picandnix:

How's about a button on the Who's Online page (per visitor) to click 'block this IP' which would add that IP to the blocked list?
Any thoughts or a proper pain in the proverbial to implement?
The IP-blocker code requires some restructuring (which is kind of on my list, anyway) to allow this to happen in a non-kludgy way. It would also require some form of consolidation, as mc12345678 referred to a couple of posts ago, to keep the database from (potentially) getting too large.

picandnix:

How's about a button on the Who's Online page (per visitor) to click 'block this IP' which would add that IP to the blocked list?
Any thoughts or a proper pain in the proverbial to implement?

lat9:

The IP-blocker code requires some restructuring (which is kind of on my list, anyway) to allow this to happen in a non-kludgy way. It would also require some form of consolidation, as mc12345678 referred to a couple of posts ago, to keep the database from (potentially) getting too large.

Of course that was why I was asking about how some parts work, I'm looking to incorporate the "process" into User Tracking (reflects a log or history of actions not just what is happening at that one moment). Still trying to consider a button, or a link to implement, but I think a button/form is the right way to go. Allows a Post operation, etc.

Trying to contemplate/minimize resource use, single read of all the blocked/allowed ip addresses from the database, be able to compare each logged entry against both the block and allow lists and then provide the applicable button(s) add to allow, add to block, if covered in both the blocked and allowed an appropriate an understandable choice.

Was also looking at the effect if any of continuing to capture the "presenece" or attempt of the "offender" to access the site if that is not yet afforded. Otherwise, some of the options above would be useless, as it would not be known that a blocked visitor attempted to access the site, and then would more than likely have to dig through server logs to confirm the ip address used by the individual that was blocked. Okay too much thought for a Saturday morning. Would certainly appreciate any code streamlining, but in the meantime gonna "make it work" :)

v2.0.2 is now available in the Plugins area.

lat9:

v2.0.2 is now available in the Plugins area.

Great!

So, had a question and just skimming the posted notes about this version. I'm trying to figure out why the init_ip_blocker file doesn't appear in the list of loaded files when on a page, why the two functions inside it are not "available" for "use" and how to make them available without potentially sacrificing security if that was the reason the file was coded/loaded the way it was. :/

Insight? Is it the load point that forced it to not remain as always visible, and was that a security determination (on purpose), or just shear luck? :P

mc12345678:

Great!

So, had a question and just skimming the posted notes about this version. I'm trying to figure out why the init_ip_blocker file doesn't appear in the list of loaded files when on a page, why the two functions inside it are not "available" for "use" and how to make them available without potentially sacrificing security if that was the reason the file was coded/loaded the way it was. :/

Insight? Is it the load point that forced it to not remain as always visible, and was that a security determination (on purpose), or just shear luck? :P
I'm not sure what you mean by "the init_ip_blocker file doesn't appear in the list of loaded files when on a page" nor do I understand why the functions wouldn't be available for use. It's an initialization file, not a class, so calling the function ip_blocker_block anytime after checkpoint 71 (when the init-file is loaded) should work just fine.

lat9:

I'm not sure what you mean by "the init_ip_blocker file doesn't appear in the list of loaded files when on a page" nor do I understand why the functions wouldn't be available for use. It's an initialization file, not a class, so calling the function ip_blocker_block anytime after checkpoint 71 (when the init-file is loaded) should work just fine.

I think I figured it out... The init file with related functions are only loaded on the store side, and not from the init_loader on the admin side. The plugin I'm revising provides data review from the admin side and I was incorrectly "expecting" it to use code that is on the store side. I'll have to add a call to the store's version for once a user has logged in. BTW, appears that if a user has been able to login to the admin panel the ip_blocker won't stop them until at least they timeout or logout and then try to login again. But, by calling the function(s) from the admin init_includes, then ip addresses will be controlled for logged in users as well. (like it or not... :P) That said, and if it was by design to not be able to stop someone that is already logged into the admin, then the alternate fix is to move/copy the functions in the init_ip_blocker file to a location reachable from both the store and the admin, preferably without having to be duplicated in the other side.

Would you mind taking the discussion of your plugin that's under development to a separate thread, please. I'd be happy to answer any additional questions that you have there.

picandnix:

How's about a button on the Who's Online page (per visitor) to click 'block this IP' which would add that IP to the blocked list?
Any thoughts or a proper pain in the proverbial to implement?

lat9:

The IP-blocker code requires some restructuring (which is kind of on my list, anyway) to allow this to happen in a non-kludgy way. It would also require some form of consolidation, as mc12345678 referred to a couple of posts ago, to keep the database from (potentially) getting too large.
I've submitted v2.1.0 to the plugins area. This version provides a single screen for the admin configuration, provides IP address "consolidation", no longer used two database fields to store your selections (to reduce database space) and includes, if the IP Blocker is enabled, a link next to each IP address in the whos_online script's display, allowing you a single-click add to the blocked IP address list.

lat9:

I've submitted v2.1.0 to the plugins area. This version provides a single screen for the admin configuration, provides IP address "consolidation", no longer used two database fields to store your selections (to reduce database space) and includes, if the IP Blocker is enabled, a link next to each IP address in the whos_online script's display, allowing you a single-click add to the blocked IP address list.

You are an absolute STAR Lat9 :hug:

lat9:

I've submitted v2.1.0 to the plugins area. This version provides a single screen for the admin configuration, provides IP address "consolidation", no longer used two database fields to store your selections (to reduce database space) and includes, if the IP Blocker is enabled, a link next to each IP address in the whos_online script's display, allowing you a single-click add to the blocked IP address list.

picandnix:

You are an absolute STAR Lat9 :hug:

And I'll review the changes (once available) to modify what I've incorporated into user tracking which offers such a button and some unblocking code also.

lat9:

I've submitted v2.1.0 to the plugins area. This version provides a single screen for the admin configuration, provides IP address "consolidation", no longer used two database fields to store your selections (to reduce database space) and includes, if the IP Blocker is enabled, a link next to each IP address in the whos_online script's display, allowing you a single-click add to the blocked IP address list.

Sorry to be a fuss ar$e, but in keeping with previous updates could you indicate in the read me the changed files please for ease of updating.

lat9:

I've submitted v2.1.0 to the plugins area. This version provides a single screen for the admin configuration, provides IP address "consolidation", no longer used two database fields to store your selections (to reduce database space) and includes, if the IP Blocker is enabled, a link next to each IP address in the whos_online script's display, allowing you a single-click add to the blocked IP address list.

Was also thinking, sort of liked the always will not be blocked option of having the second box. That way and it is a plus as well as potential negative, could assign an address not to be blocked and could block everything else around it. Oh well..

picandnix:

Sorry to be a fuss ar$e, but in keeping with previous updates could you indicate in the read me the changed files please for ease of updating.
For v2.1.0, treat it as if every file in the /YOUR_ADMIN directory has changed (it's close!); no changes on the store-side.

mc12345678:

Was also thinking, sort of liked the always will not be blocked option of having the second box. That way and it is a plus as well as potential negative, could assign an address not to be blocked and could block everything else around it. Oh well..
If you're thinking that the Allowed IP List disappeared, you're mistaken. If that's not what you implied, please restate.

lat9:

If you're thinking that the Allowed IP List disappeared, you're mistaken. If that's not what you implied, please restate.

That is what I thought to understand based on the statement of revision: > This version provides a single screen for the admin configuration, provides IP address "consolidation", no longer used two database fields to store your selections (to reduce database space)

Regardless, and if the option is still there, I will need to review how the assignments are made and what I did to incorporate them. I thought I used functions existent with what was included with this plugin, so that changes would not require reprogramming, but still will need to look at the package to see what changes might be necessary. I had figured out ways to do things like take an ip span of allowed ip's and block just one of the ip addresses in it and keep a span of addresses rather than explode all of the addresses. Of course that depends on the number of addresses in the span and where in the span the address was (first, last, one away from either, somewhere in the middle) and block that one address. I hadn't worked out yet a make a span of addresses based on existing "neighboting" addresses, but figured that might be something to do after a large number had been identified.

I also am trying to figure out what it will take to include in the user tracking list ip addresses that have attempted to use the special signin area, but haven't tried hard enough. So far issue is that user tracking relies on the footer being loaded, and it almost seems that there is no desire to do that in this plugin, because of the nature of it's features, so, need to figure out what code and in what "format" to load it from user tracking so that with ip blocker being loaded when it is and "redirecting" to the special login page, that data can still be captured.

lat9:

For v2.1.0, treat it as if every file in the /YOUR_ADMIN directory has changed (it's close!); no changes on the store-side.

Thank you Lat9.

mc12345678:

That is what I thought to understand based on the statement of revision:.
Previous versions of the plugin stored the expanded IP list used in the store-side processing as well as the "textarea" editable/viewable version used by the admin for each of the block- and allow-lists. This version of the plugin no longer stores the "textarea" editable/viewable format, but simply calculates the display information from the store-side information.

I've asked before ... could we ***please ***use this thread as the support thread for the IP Blocker?

I've just updated to 2.1.0 and I've received an error log file

PHP Warning: implode(): Invalid arguments passed in /home/MYACCOUNT/public_html/MYADMIN/ip_blocker.php on line 70

I did an overwrite of the aforementioned file from previous version.

Any thoughts gratefully received.

Arggh. :censored: That because the previous version didn't encode an empty string properly (I'm guessing that your previous "Allowed IP Address" list was blank). Patch forthcoming ...