KR. Laboratories

We did not change any settings. All settings are by default.

Thus, disabling Bot Flight Mode in the Cloudflare CDN allowed QUIC Cloud to successfully connect to our server and approve the domain key. I think it would be good to mention this in the documentation. Thank you for your answers and technical support.

Is there any way we can bypass this blocking without disabling additional protection Cloudflare? For example, add your IP lists to the allowed ones?

Thanks!

Report ID: PBYPAFVK

Just now we added HTTP-header, you can check it here:
https://securityheaders.com/?q=https%3A%2F%2Fkr-labs.com.ua&followRedirects=on

Thanks for recommendation:
“…and also , please keep the debug log enabled to admin IP , track the purge call , let’s see what was the purge log when this happens or what triggered the purge”.

Hope it helps, because really tired from this.

After 1 month, the situation repeated itself. Today we found out that the site was not loading due to a Litespeed error:

The resource from “https://kr-labs.com.ua/wp-content/litespeed/js/323f74d7b8cdf3323ac88876f88d7360.js?ver=b87a8” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).

If we don’t get proper support and a solution to this issue, we will probably be forced to remove the plugin. I suspect that this caching plugin is vulnerable to some attacks with MIME type.

P.S. And again, after manually clearing the cache, the problem disappeared. I ask you why?

• This reply was modified 1 year, 4 months ago by KR. Laboratories.
• This reply was modified 1 year, 4 months ago by KR. Laboratories.

Today our website has stopped rendering again through an error:

e06081caa22b174d81151dfe30d7da2d.js:1 Failed to load resource: the server responded with a status of 404 ()
Refused to execute script from ‘https://kr-labs.com.ua/wp-content/litespeed/js/e06081caa22b174d81151dfe30d7da2d.js?ver=5d4ed’ because its MIME type (‘text/html’) is not executable, and strict MIME type checking is enabled.

Screenshots:
https://imgur.com/Zml80hd.png
https://imgur.com/JExrbAr.png

Report ID: LXLMFRVE

Why LiteSpeed does not update the old cache ??? Cronjob enabled and working.

Only complete manual clean cache solves this problem. But it should not be. Either there is some reason on our side or on the side of the plugin …

And it happens periodically. Can it be an attack with the intercepting or breakdown of LITESPEED cache?

We finally try follow this guide: https://openlitespeed.org/kb/how-to-set-up-custom-headers/

• This reply was modified 1 year, 5 months ago by KR. Laboratories.
• This reply was modified 1 year, 5 months ago by KR. Laboratories.
• This reply was modified 1 year, 5 months ago by KR. Laboratories.
• This reply was modified 1 year, 5 months ago by KR. Laboratories.
• This reply was modified 1 year, 5 months ago by KR. Laboratories.
• This reply was modified 1 year, 5 months ago by KR. Laboratories.
• This reply was modified 1 year, 5 months ago by KR. Laboratories.
• This reply was modified 1 year, 5 months ago by KR. Laboratories.
• This reply was modified 1 year, 5 months ago by KR. Laboratories.
• This reply was modified 1 year, 5 months ago by KR. Laboratories.
• This reply was modified 1 year, 5 months ago by KR. Laboratories.
• This reply was modified 1 year, 5 months ago by KR. Laboratories.

We have activated the server scheduler cronjob, but instead wget/curl used php command.
Thank you for your recommendations, we will try to apply them and then let you know the result.

[14/Aug/2023:02:49:04 +0000] “GET /wp-content/litespeed/js/122a1aa4cf141f4b729b819f2c8b5cc4.js?ver=894d8 HTTP/2” 404 705
[14/Aug/2023:02:49:04 +0000] “GET /wp-content/litespeed/css/fc60e8d00be11baf933646794d3d3391.css?ver=894d8 HTTP/2” 404 705
[14/Aug/2023:02:49:05 +0000] “GET /wp-content/litespeed/css/7fe525c03358a56785eb0543faa5f612.css?ver=894d8 HTTP/2” 404 705
[14/Aug/2023:02:49:05 +0000] “GET /wp-content/litespeed/js/cfc2b583f5459d49a5d79473328345ee.js?ver=894d8 HTTP/2” 404 705
[14/Aug/2023:02:49:06 +0000] “GET /wp-content/litespeed/css/b07116c17f8645fe8f8980f2aca92687.css?ver=894d8 HTTP/2” 404 705
[14/Aug/2023:02:49:06 +0000] “GET /wp-content/litespeed/js/fedd9590d8dbff14ce5a64374f1ce301.js?ver=894d8 HTTP/2” 404 705
[14/Aug/2023:02:49:07 +0000] “GET /wp-content/litespeed/js/fedd9590d8dbff14ce5a64374f1ce301.js?ver=894d8 HTTP/2” 404 705

I also don’t know why one day these cached versions of files started returning 404s, and the layout of the site was damaged.

• This reply was modified 1 year, 6 months ago by KR. Laboratories.

Report number: XDWFGXTU

Dear Takayuki,

Your plugin is great, but text field validation and antispam system are slightly different things. There is such a thing as Client-Side Form Validation. According to its logic, each text line field should allow a certain value. For example, the name field accepts only text, the phone field accepts only numbers. I want to implement this logic. That’s why I’m wondering if there are any built-in solution on the Contact Form side, maybe some hooks through functions.php. The fact that you can enter numbers instead of a name – I consider it a violation of the form logic and a violation of the security policy. Such form will not pass the pentest. I want, that CF7 users to be able to configure field validation according to security standards, not just enable the antispam system and block requests from a specific IP/User-Agent, etc.

Best regards and thanks for your work!

• This reply was modified 1 year, 6 months ago by KR. Laboratories.

I already fixed it by @media in CSS, but recommend developers to add the exclusion feature on mobile devices. thanks.

I would like to add more information to this issue. I noticed, that this problem with redirect occurs through the advanced-cache.php file. If in WP-FFPC plugin Save changes again – this file starts working correct and there are no problems. I think it’s a bug. Please, fix it.

• This reply was modified 4 years, 11 months ago by KR. Laboratories.

Hi, @davidanderson
Thank you for answer!
Yes, i already report it to them.

I solved this problem – added in .htaccess 301 rediret manually from non-slash to slash URLs:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]

</IfModule>

But I don’t think this is the perfect solution for this problem. Web developers need to test this case, because it occurs on absolutely all sites with WP-FFPC + WP-OPTIMIZE