Diagnostics Extended related (bug + question)

[servicioexpreso]

1. Plugin drop huge amount of warnings related to OPcache.

2. What mean (how to fix?) warning:

" config/config.ini.php seems to be semi-public. While attackers can’t read the config now, the file is publicly accessible and if for whatever reason your webserver stops executing PHP files in the future, everyone can read your MySQL credentials and more. Please check your webserver config."

3. What mean (how to fix?) warning:

“matomo.js is not delivered gzipped. You might want to set up gzip for .js files as it can reduce the size of the file by up to 60 %.”

I run Matomo on Plesk with LiteSpeed server.

[Lukas (Lukas Winkler)]

Hi,

Keep in mind I published the plugin as experimental yesterday and didn’t have the time yet to check it in different Matomo setups, so some warnings can be straight up wrong.

@servicioexpreso

Plugin drop huge amount of warnings related to OPcache.

I personally think it is a good idea to enable OPcache for Matomo, so I added a few checks to see if it is enabled and if it has enough memory for caching. For more hints I would need the exact error message.

@servicioexpreso

" config/config.ini.php seems to be semi-public

The config.ini.php contains secret values like your MySQL password. So I would recommend you to set up your webserver to not allow anyone to access files in config/.
Thankfully the file is a .php file so people accessing it can’t see its content, but if you for whatever reason one day misconfigure your webserver so that .php files are not executed, but served to the user, they get the MySQL password.

So it is better to be save and protect the config/ directory. The Matomo .htaccess files and the official nginx config should do this correctly.

@servicioexpreso

What mean (how to fix?) warning:

Check how your webserver delivers your matomo.js on a tracked website in the network tab of your browsers developer tools. You should see a content-encoding: gzip HTTP header as your webserver compresses the JS file with gzip to make the JS file a lot smaller. If it doesn’t I recommend you to look up the documentation for LiteSpeed on how to serve files gzipped as it reduces the amount of data transferred by 2/3.

[servicioexpreso]

@Lukas

So it is better to be save and protect the config/ directory. The Matomo .htaccess files and the official nginx config should do this correctly.

Yeah, but question was - how exactly to do it?

[servicioexpreso]

@Lukas

personally think it is a good idea to enable OPcache for Matomo, so I added a few checks to see if it is enabled and if it has enough memory for caching. For more hints I would need the exact error message.

1. Why OPcache if Redis run?
2. Do you want to attach those warnings?

[servicioexpreso]

@Lukas

Check how your webserver delivers your matomo.js on a tracked website in the network tab of your browsers developer tools. You should see a content-encoding: gzip HTTP header as your webserver compresses the JS file with gzip to make the JS file a lot smaller. If it doesn’t I recommend you to look up the documentation for LiteSpeed on how to serve files gzipped as it reduces the amount of data transferred by 2/3.

It deliver as JS. Good idea. I will ask LS support and post reply here for eventual need of other users who use OpenLiteSpeed (there is no support).

[Lukas (Lukas Winkler)]

@servicioexpreso

Yeah, but question was - how exactly to do it?

I don’t know LiteSpeed, but something like this looks related:

How can I deny access to a folder in OpenLiteSpeed similarly to the way Apache does it?

https://openlitespeed.org/kb/access-control/

@servicioexpreso

Why OPcache if Redis run?

OPcache has nothing to do with application-level caching. As you probably know, PHP is an interpreted language. This means that every time a PHP file is access the code in it needs to be parsed and interpreted. OPcache allows to store the output of the parser in memory meaning that the next time the PHP file is executed one can directly use the parsed data from memory.

This can speed up PHP execution by a bit as it avoids doing the exact same thing on every request.

[ograssini (Oswaldo)]

Hey @Lukas
I installed this plugin on my Matomo system and i got those message error:

WARNING: C:\Websites\matomo\plugins\DiagnosticsExtended\Diagnostic\MatomoJsCheck.php(77): Notice - Undefined index: content-type - Matomo 4.2.1 - Please report this message in the Matomo forums: https://forum.matomo.org (please do a search first as it might have been reported already) (Module: Installation, Action: systemCheckPage, In CLI mode: false)

×

WARNING: Exception: curl_exec: Operation timed out after 1128 milliseconds with 0 bytes received. Hostname requested was: php.net in C:\Websites\matomo\core\Http.php:677 Stack trace: #0 C:\Websites\matomo\core\Http.php(101): Piwik\Http::sendHttpRequestBy(‘curl’, ‘https://php.net…’, 2, ‘Mozilla/5.0 (Wi…’, NULL, NULL, 0, ‘’, false, false, false, ‘GET’, NULL, NULL) #1 C:\Websites\matomo\plugins\DiagnosticsExtended\Diagnostic\PhpVersionCheck.php(73): Piwik\Http::sendHttpRequest(‘https://php.net…’, 2) #2 C:\Websites\matomo\plugins\Diagnostics\DiagnosticService.php(68): Piwik\Plugins\DiagnosticsExtended\Diagnostic\PhpVersionCheck->execute() #3 C:\Websites\matomo\plugins\Diagnostics\DiagnosticService.php(54): Piwik\Plugins\Diagnostics\DiagnosticService->run(Array) #4 C:\Websites\matomo\plugins\Installation\Controller.php(494): Piwik\Plugins\Diagnostics\DiagnosticService->runDiagnostics() #5 [internal function]: Piwik\Plugins\Installation\Controller->systemCheckPage() #6 C:\Websites\matomo\core\FrontController.php(605): call_user_func_array(Array, Array) #7 C:\Websites\matomo\core\FrontController.php(166): Piwik\FrontController->doDispatch(‘Installation’, ‘systemCheckPage’, Array) #8 C:\Websites\matomo\core\dispatch.php(32): Piwik\FrontController->dispatch() #9 C:\Websites\matomo\index.php(25): require_once(‘C:\Websites\mat…’) #10 {main} (Module: Installation, Action: systemCheckPage, In CLI mode: false)

×

WARNING: C:\Websites\matomo\plugins\DiagnosticsExtended\Diagnostic\MatomoJsCheck.php(86): Notice - Undefined index: content-encoding - Matomo 4.2.1 - Please report this message in the Matomo forums: https://forum.matomo.org (please do a search first as it might have been reported already) (Module: Installation, Action: systemCheckPage, In CLI mode: false)

thank you
Oswaldo

[servicioexpreso]

@Lukas

Check how your webserver delivers your matomo.js on a tracked website in the network tab of your browsers developer tools. You should see a content-encoding: gzip HTTP header as your webserver compresses the JS file with gzip to make the JS file a lot smaller. If it doesn’t I recommend you to look up the documentation for LiteSpeed on how to serve files gzipped as it reduces the amount of data transferred by 2/3.

OK, so to inform you that you should to add also check not just for gzip, but also for br ( Brotli) as LiteSpeed using br compression by default. Basically, your plugin drop out false warning about possible improvements as going from br to gzip is actually kind of ‘downgrade’.

[servicioexpreso]

@Lukas

I don’t know LiteSpeed, but something like this looks related:

Well, … it looks that your idea is actually wrong.

1. First, LiteSpeed support reply

How to secure installation of Matomo application is neither LiteSpeed nor Plesk’s area. You should check the Matomo application installation recommendation from their website. It is application-level support and the application developer has better knowledge about that.

2. Also, if we observe your plugin finding

config/config.ini.php seems to be semi-public. While attackers can’t read the config now, the file is publicly accessible and if for whatever reason your webserver stops executing PHP files in the future, everyone can read your MySQL credentials and more. Please check your webserver config.
.git/info/exclude doesn’t seem to be publicly reachable
tmp/cache/token.php doesn’t seem to be publicly reachable
cache/tracker/matomocache_general.php doesn’t seem to be publicly reachable
lang/en.json doesn’t seem to be publicly reachable

one simple fact is very easy visible. Matomo developers decided that some files are private and some semi-public. So. if we now observe LS support reply, logical question is → Why Matomo developers decided to not make file private (obviously they could to do it if they wanted)?

Do you have answer on that?

[Lukas (Lukas Winkler)]

Thanks for the feedback everyone:

@ograssini the three warnings should all now be fixed.

@servicioexpreso

you should to add also check not just for gzip, but also for br

You are of course right, I didn’t think of brotli. It should now also consider brotli as correct.

@servicioexpreso

Matomo developers decided that some files are private and some semi-public.

Yes, but the only thing the Matomo developers can influence and use to protect files are the .htaccess files (which don’t protect the files when using LiteSpeed) and pointing people to the nginx config that protects these files.
If your webserver serves these files there is nothing Matomo can do to stop it.

There is one exception: One could put these files outside the web-root. But unfortunatly Matomo is used by a ton of users who don’t know what that means and are using webhosts that don’t allow them to influence the web-root, so that’s why every Matomo file is inside or below the same directory.

If you have an idea how this could be solved, I am looking forward to hearing it.

All of this should be released in 0.1.4.