search

matomo-org / matomo

Empowering People Ethically with the leading open source alternative to Google Analytics that gives you full control over your data. Matomo lets you easily collect data from websites & apps and visualise this data and extract insights. Privacy is built-in. Liberating Web Analytics. Star us on Github? +1. And we love Pull Requests!
https://matomo.org/
GNU General Public License v3.0
19.91k stars 2.65k forks source link

System Checks might not work for internal hostname without TLD #18567

Open Starker3 opened 2 years ago

Starker3 commented 2 years ago

A user encountered an error in the System Check (Specifically for the HSR plugin). The check showed that the URL was not accessible. After further testing they confirmed that devices on the network can access the link and they are able to use cURL and wget to access the URL from the Matomo server directly and it returned the expected results.

The main thing that appears to be different is that this is an internal only Matomo server that does not use a TLD. So for example it's just using a URL such as: https://matomo-site/matomo/plugins/

The same result showed when doing the System Check in the UI and through a console command.

bx80 commented 2 years ago

I can confirm this locally, as I use a non-TLD self signed server config and the following error is shown:

Requesting 'https://matomo/plugins/HeatmapSessionRecording/configs.php?idsite=1&trackerid=5lX6EM&url=http%3A%2F%2Ftest.test%2F' resulted in an error: curl_exec: operation timed out after 2001 milliseconds with 0 bytes received. hostname requested was: matomo. As a result, tracking Heatmaps and Session Recordings may not work. You may need to change your webserver configuration to allow access to this file via the Internet or Intranet.

A quick hack to disabling the CURL_VERIFYPEER and CURL_VERIFYHOST options on the request allows the check to complete successfully, so this error is probably caused by CURL rejecting the self signed certificate.

Although the HSR check could be changed make the request with the $acceptInvalidSslCertificate parameter, I don't think we'd want to accept invalid certs by default.

It might be better to have a config option to always allow self signed certificates for specific named hosts so internal server setups with https can be supported.

Something like:

[General]
ignore_invalid_ssl_certs_for_hosts[] = "matomo"

Then sendHttpRequestBy() could disable CURL_VERIFYPEER and CURL_VERIFYHOST options if the request if for a host in that list.

Starker3 commented 2 years ago

Could this maybe be resolved by using a custom certificate bundle then? There is a config option for it: https://github.com/matomo-org/matomo/blob/4.x-dev/config/global.ini.php#L833

Starker3 commented 2 years ago

FYI not sure if the user is seeing the same error message as you do:

Error: The URL '$MATOMO_URLplugins/HeatmapSessionRecording/configs.php?idsite=1&trackerid=5lX6EM&url=http%3A%2F%2Ftest.test%2F' seems to be not accessible from the Internet or Intranet. As a result, tracking Heatmaps and Session Recordings may not work. You may need to change your webserver configuration to allow access to this file via the Internet or Intranet.
bx80 commented 2 years ago

Looks like it's a different issue from ssl certs then. That message is shown if there was a response but it didn't include the string piwik.heatmapsessionrecording, unfortunately the HSR check doesn't write a debug log with the exact response.

What is shown if https://matomo-site/matomo/plugins/HeatmapSessionRecording/configs.php?idsite=1&trackerid=5lX6EM&url=http%3A%2F%2Ftest.test%2F is accessed with a web browser?

Starker3 commented 2 years ago

It's shows the expected output: image

wget an cURL return the same response as well when executed from the Matomo server:

root@vmt-webstat-01:/tmp]# wget 'https://webstat-tst/matomo/plugins/HeatmapSessionRecording/configs.php?idsite=1&trackerid=5lX6EM&url=http%3A%2F%2Ftest.test%2F'

--2021-12-17 11:02:36-- https://webstat-tst/matomo/plugins/HeatmapSessionRecording/configs.php?idsite=1&trackerid=5lX6EM&url=http%3A%2F%2Ftest.test%2F

Resolving webstat-tst (webstat-tst)... 172.26.X.X

Connecting to webstat-tst (webstat-tst)|172.26.X.X|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [application/javascript]

Saving to: 'configs.php?idsite=1&trackerid=5lX6EM&url=http:%2F%2Ftest.test%2F'

configs.php?idsite=1&trackerid=5lX6EM&url=http: [ <=> ] 116 --.-KB/s in 0s

2021-12-17 11:02:36 (85.6 MB/s) - 'configs.php?idsite=1&trackerid=5lX6EM&url=http:%2F%2Ftest.test%2F' saved [116]

[root@vmt-webstat-01:/tmp]# cat 'configs.php?idsite=1&trackerid=5lX6EM&url=http:%2F%2Ftest.test%2F'

Piwik.HeatmapSessionRecording.configuration.assign({"heatmaps":[],"sessions":[],"idsite":"1","trackerid":"5lX6EM"});
bx80 commented 2 years ago

The output looks okay and there clearly isn't any issue with server itself accessing it. I think we'll need to see details of the response or error to work out why the check code is failing.

Would it be possible to temporarily add the following line to plugins/HeadmapSessionRecording/Diagnostic/ConfigsPhpCheck.php on line 80 just after the try/catch block then try ./console diagnostics:run?

\Piwik\Container\StaticContainer::get(\Psr\Log\LoggerInterface::class)->error("Response:".json_encode($response)." Error: ".$error);

That should spit out an error showing the exact response and any possible exception message.

If that's not appropriate then I could submit a PR for the HSR plugin to add some detailed debug logs for when this check fails, but that would only be available in the next plugin release.