@Starker3 opened this Issue on January 4th 2022 Contributor

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 on January 4th 2022 Contributor

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 on January 4th 2022 Contributor

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 on January 4th 2022 Contributor

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 on January 5th 2022 Contributor

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 on January 5th 2022 Contributor

It's shows the expected output:
image

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

root<a class='mention' href='https://github.com/vmt'>@vmt</a>-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<a class='mention' href='https://github.com/vmt'>@vmt</a>-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 on January 5th 2022 Contributor

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.

Powered by GitHub Issue Mirror