Advanced Traffic Statistics: Live Radar, WAF & AI Security

Advanced Traffic Statistics: Live Radar, WAF & AI Security 1.8.3

No permission to download
We are running php 8.2.30 and MySQL 8.0.45. All of the tables in the database are innodb_utf8mb4_unicode_ci except three addon tables that are utf8mb3_general_ci for au lait LAU (119 rows), xfa fss transaction (0 rows), xfa Who Read Content (1847974 rows).

Who Read Content is important to us but it was set up with no limit on how long to hold data. There is a problem with the addon that is not allowing me to change the value to save the maximum events count. I will try to sort that out with XFA.

I do not know if this information will help in resolving what is going on with our system and your package.
 
We are running php 8.2.30 and MySQL 8.0.45. All of the tables in the database are innodb_utf8mb4_unicode_ci except three addon tables that are utf8mb3_general_ci for au lait LAU (119 rows), xfa fss transaction (0 rows), xfa Who Read Content (1847974 rows).

Who Read Content is important to us but it was set up with no limit on how long to hold data. There is a problem with the addon that is not allowing me to change the value to save the maximum events count. I will try to sort that out with XFA.

I do not know if this information will help in resolving what is going on with our system and your package.

Thank you for this detailed report. This information is extremely helpful and explains exactly why you are seeing the MySQL 3988 error.

Your server environment (PHP 8.2.30 and MySQL 8.0.45) is actually excellent and very modern. The problem is not the software version, but a "collation conflict" caused by those three specific tables, especially xfa_Who_Read_Content.

Why this causes the error:When XenForo tries to install or upgrade an add-on, it opens a "transaction." If the process touches or even just "sees" tables with different collations (mixing the old utf8mb3 with the modern utf8mb4), MySQL 8.0 blocks the operation for safety. The fact that the "Who Read Content" table has 1.8 million rows makes this conflict much more likely to trigger a timeout or a transaction lock.

The Solution:Since you have a system consultant, you can ask them to perform these two steps. It will not only fix the installation of my add-on but also make your entire forum more stable and faster:

  1. Convert the three tables: Ask your consultant to convert au_lait_lau, xfa_fss_transaction, and especially xfa_Who_Read_Content to utf8mb4_unicode_ci. This will align them with the rest of your database.
  2. XenForo Built-in Tool: XenForo actually has a built-in tool for this. Your consultant can run this command via CLI:php cmd.php xf:convert-utf8mb4(Note: Since the "Who Read Content" table is very large, they should run this via CLI to avoid web-server timeouts).
Regarding the XFA add-on issue:The reason you can't save the "maximum events count" might be related to this same database mismatch or the massive size of the table. Standardizing the collation often fixes these "unresponsive" settings as well.

Once those 3 tables are aligned to utf8mb4_unicode_ci, our add-on (and any other future updates) will install instantly without any errors.

Important: Full Backup before proceeding
 
Just a heads up on the misc/style-variation bot that keep hammering our sites.

I use the free version of cloudflare and they are also my registrar.
So, since I had already used up my free security rules, I deleted the least activated rule.

Then I created a new security rule.

Gave it a name,
Selected "URI Path" in the Field dropdown,
Selected "contains" in the Operator dropdown,
Entered the phrase style-variation into the Value Box,
Selected "Block" in Choose Action,
And whatever order you want it to be at in your list of rules (doesn't matter)
Click or tap the save button.

It will be active within a minute.

So far in my first 10 minutes cloudflare has blocked 350+ of these string requests.
Yes my site was being hit that hard.

So, so far so good.
 
Just a heads up on the misc/style-variation bot that keep hammering our sites.

I use the free version of cloudflare and they are also my registrar.
So, since I had already used up my free security rules, I deleted the least activated rule.

Then I created a new security rule.

Gave it a name,
Selected "URI Path" in the Field dropdown,
Selected "contains" in the Operator dropdown,
Entered the phrase style-variation into the Value Box,
Selected "Block" in Choose Action,
And whatever order you want it to be at in your list of rules (doesn't matter)
Click or tap the save button.

It will be active within a minute.

So far in my first 10 minutes cloudflare has blocked 350+ of these string requests.
Yes my site was being hit that hard.

So, so far so good.
Hi!

While your rule is definitely effective at stopping the bot attack, I would like to issue a small "heads-up" for everyone using XenForo 2.3.

The string style-variation is actually a core part of XenForo 2.3's native functionality. It is used by the system to handle Style Variations (switching between Light and Dark modes).

If you block all URIs containing that string:

  • Legitimate users will be unable to switch between Light and Dark modes (the request will be blocked by Cloudflare).
  • Some browsers might fail to load the correct CSS variation automatically, potentially causing display issues.
A better approach:Instead of a flat "Block" on the URI, you might want to combine the rule with a User-Agent check or use a JS Challenge (Managed Challenge) instead of a hard Block. This way, real users with a browser will pass the challenge and be able to switch styles, while the "dumb" bots hammering your site will still be stopped.

Thanks for sharing your results, but be careful if you notice your users complaining about the dark/light mode toggle not working!
 
Thanks for sharing your results, but be careful if you notice your users complaining about the dark/light mode toggle not working!
Thank you for the advice.

My site is exclusively dark mode only and I do not allow any style changes. Light or Dark. So no worries there.

But I did note that when I enter https ://websitename.com/misc/style-variation into my browser, the page it led to was a simple forum page with the style selector visable. (which i have hidden on my site)

Since I added the cloudflare rule, when I enter that url into the browser, I get the standard cloudflare Blocked page. So that part is identifiable as working.

I will have to do some study and testing to see if I need to add a user agent check, or a js challenge. (I hate using the challenge as I prefer to go straightaway to just blocking. That uri string isn't used by real human visitors on my site.)


Thank you for all your help, and I hope others that experience this type of problem consider a free cloudflare account, at minimum, along with adding a security rule. I know I am not alone in this. ;)

(I can breath now, my traffic went down from over 15,000 of these hits since 24 hours and now I am down to my normal hundreds per day of actual traffic.)
 
Last edited:
Back
Top Bottom