Plugin does not honor database settings

Hi tarun80!

Sorry, word honor is not applicable here.

1. Tables is not prefixed intentionally. First of all, it gives ability to manage and protect multi site installations as whole. Secondly, the plugin tracks all attempts comes from “bad guys” in one shared, common table. That allows to block IP addresses globally on every site in multisite installation. Thirdly, network administrator can manage IP Access List for all sites in one place only. There is only one disadvantage: users are unable to backup and restore IP Access Lists if they have ones, but know nothing about DB schema. They should manually add table CERBER_ACL in a list of tables that will be backed up and restored.

2. Collation utf8_general_ci is more than enough to work as intended and properly in any DB. Possibly there may be some issues with Japanese/China languages in context of lockouts explanations column on lockouts screen, but no functionality may be involved here.

3. To disable WHOIS uncheck Drill down IP option in the main settings of the plugin.

1. I’d like to at least have an option to have my database table prefixed. I believe it makes it much neater and allows you to know what it’s associated with. Example: jos_ for Joomla, drupal_ for Drupal, etc. This allows for the database to be kept tidy and organized.

Another example would be if there is a multisite and your plugin is also covering the main site. They use a test site/install and want to test a beta version of your plugin or user made modifications. That could potentially wipe the entire site if something goes wrong.

I personally use a local test/dev environment to see how it goes. Separate databases and all so nothing touches my live site or risks taking it down.

I do hope you can add that option.

2. Why not honor the settings that WordPress is using? A clean install of WordPress shows it’s currently using: utf8mb4_unicode_520_ci. I believe a plugin should honor those settings for consistency. utf8_general_ci seems to be frowned upon moreso than in the past, what with emojis and all the other characters, etc. now available for use.

3. Must be a bug, mine is unchecked and it still performs a WHOIS on every entry.

1. Probably it’s reasonable. I agree with you. But it will be a PHP constant definition.
2. Why I should honor (and track all changes) some setting that I do not use anywhere? Should I waste my time on that? Sorry, no. Just for consistency? Sorry, no. I can change it only for compatibility with Japanese/China languages.
3. If you mean Hostname column, yes you cannot disable it for now. If no, please explain me where do you get WHOIS requests?

Anyway, thanks for your arguing!

1. Thank you for taking the prefix option into consideration. That may be helpful for some who use a single database for multiple entries. I was just thinking, I’ve seen Mediawiki plugins sometimes not do prefixes so that can also add to confusion for some.

2. I may test it on my dev environment by manually switching the collation and seeing how it performs.

3. Yes, it was the hostname column.

Why do you need to disable Hostname column?

Because it takes time to resolve each entry? I’d rather have it on demand instead of resolving something I may not really care about.

Also, another thing pertaining to the database. The type is MyISAM, whereas all of WordPress uses InnoDB. Which means the tables have to be watched and occasionally optimized if you’re dealing with a lot of brute force attempts.

• This reply was modified 8 years, 1 month ago by tarun80.

What is time? How much is it take? Sending UDP request to closest DNS server? Plus, how often do you check Activity log? Please, admit this column as is for now.

WP used MyISAM tables all the time, probably up until now. I do not track in details all changes in the WP tables. Anyway, I don’t see any reason to use InnoDB tables for such kind of application.

Time can vary between 5-20 seconds. Checked by counting myself and with Inspect Element -> Network in Firefox.

The tables Cerber uses should be based upon the values that WP itself uses. If WP is using InnoDB, so should Cerber. If WP is using table prefixes, so should Cerber unless you specifically have an option asking if it’s a multi-site install.

Resolving host names doesn’t consume noticeable amount of server resources. Please, admit Hostname column as is. That is not the task that someone needs to pay attention to. Secondly, there is no any technical reason or goal for having DB tables based on “WP values”.

Having to wait 20 seconds for it to finish loading is an issue. Especially when the setting to resolve the IP addresses has been unchecked, that was the reason I unchecked it. Because I did not need every single IP address to be resolved.

Then can you explain why it’s somehow acceptable to not use the same collation and database type for the tables of your plugin?

InnoDB performs better than MyISAM and also does not need to be optimized to get rid of overhead. When you get a lot of brute force attempts and the logs are regularly cleaned out, yet no optimization occurs, the overhead adds up especially on large websites. This is why it should honor what WordPress sets forth in the config.

utf8mb4_unicode_520_ci allows for any type of character to be recognized, which is a plus. Considering WordPress is a multilingual CMS, being able to support any and all characters is a plus, too. Accuracy and performance are two more major benefits to using a good collation over the older generic utf8_general_ci.

If you’d like to learn more about it, this stackoverflow is a great read.

Great explanation, thanks! You don’t need to wait some seconds for loading because, as you definitely noticed, name resolving operations performs independently via background AJAX requests. Once per page. So, you can navigate through Activity log pages without any delay. Don’t you?
Secondly, my code cache every resolved IP address for up to 24 hours by using WordPress transients. So, sometimes you will barely notice several log lines with unresolved names. Mentioned option named “Retrieve extra WHOIS information for IP”. Sorry, that means extra info, no just single name.

I agree with you on overhead and fragmentation of MyISAM tables. That’s an issue. In some circumstances it would be right to use InnoDB engine that I prefer to use too, anyway. But in this particular case we have write-intensive plugin, especially in the case of intensive brute force attacks. Every login related activity stores as a row in the log table with an index. When it comes to writing, InnoDB is slower then MyISAM due to transaction mechanism and more intensive I/O operations. Do not forget about constantly rebuilding index. So, using InnoDB will decrease performance of the plugin. This is a cost of using InnoDB that you need to accept.

Having older generic encoding utf8_general_ci doesn’t affect any of the plugin functionalities. It is possible that some Asian languages messages in the Dashboard will be displayed incorrectly. Nothing more. But using modern encoding can be cause of a problem with outdated MySQL servers. So I will use encoding safely and upgrade encoding in the 2017.

Quite welcome.

Perhaps it can be a new option to disable the DNS resolution completely? Or somehow make it a link that says click to resolve, and the resolves it in the current fashion for that row?

Looking into the differences with MyISAM and InnoDB I completely understand why it’s set up what way. The speed and efficiency, plus the difference in resources plus full text search.

Encoding changes sounds good as well, looking forward to it.

Thank you for the excellent discussion. ??

Hi tarun80!

In the last version I added MyISAM table optimization query. So, we’ve got rid of MyISAM overhead now.

I see, checking out all the nice new things now. Love the addition of reCaptcha. That reduces the number of plugins I need.