HTTP Error 0 when self-monitoring

[JackRoublard]

Hi,

I have tried to monitor my NC instance's ocs/v2.php/apps/serverinfo/api/v1/info by exactly following the instructions at https://github.com/Rello/analytics/wiki/Datasource:-JSON (Example 1), but I keep getting the "HTTP Error 0" toast and no data appears.

As a workaround I have also tried setting occ config:app:set serverinfo token and using NC-Token:token* as authentication but the error persists.

No relevant logs (such as login failures) appear in the instance logs, and I can access the json file just fine from my browser so it's not a server-side error.

Thanks in advance !

*as per the documentation at the bottom of the instance's serverinfo page.

[Rello]

Hi,

i can reproduce the error. still checking...

[Rello]

Hi,
as part of #327 I was checking this again. for me it is working now as expected.
can you retry?

[JackRoublard]

Hi, thanks for checking in

Unfortunately I still get the same result...

This might be a long shot but I'll throw that out there since anything can help with such cryptic error messages :
The way my setup differs from most users - which relates to http queries - is that I'm not using a domain + letsencrypt, but rather working with a public IP and a self-signed root authority certificate, which most browsers (and possibly requests libraries) deem "insecure". I have tried three url patterns so far : https:///, https://, https://localhost but they yield the same result.

[tautomer]

Hi, thanks for checking in

Unfortunately I still get the same result...

This might be a long shot but I'll throw that out there since anything can help with such cryptic error messages : The way my setup differs from most users - which relates to http queries - is that I'm not using a domain + letsencrypt, but rather working with a public IP and a self-signed root authority certificate, which most browsers (and possibly requests libraries) deem "insecure". I have tried three url patterns so far : https:///, https://, https://localhost but they yield the same result.

I'm facing the same problem. The self-signed certificate might indeed be the problem.
In my nginx configuration, accessing through http returns code 301. If I change the URL to http://, Analytics indeed gets HTTP response code: 301, instead of code 0.
I did check with Python's requests. Without verify=False, get just throws an error SSLCertVerificationError.
I'm not at all an expert in web stuff, but I guess the problem can be solved if there is an option to disable the verification of the certificate.

[tautomer]

By adding a line

            curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);

in analytics/lib/Datasource/Json.php, I can successfully get the data from serverinfo.

Based on php docs and this SO answer, changing line 86 in Json.php (CURLOPT_SSL_VERIFYPEER) to false should completely disable the verification, but somehow it does not work as intended. I had to disable VERIFYHOST.

It should be possible to implement a checkbox to tick CURLOPT_SSL_VERIFYHOST or an extra option CURLOPT_CAINFO (I guess our self-signed certificate should work if the .pem file is explicitly provided) in the UI.

[Rello]

Hello @tautomer
thank you for supporting this app with your analysis and solution proposal.
You are correct, we need to cover the case of "insecure" certificates.
Let me check if I either put a dedicated checkbox in - or find a flexible way to add curloptions in general on demand. This might even be more future prove if some other requirements come up

[tautomer]

Hello @tautomer thank you for supporting this app with your analysis and solution proposal. You are correct, we need to cover the case of "insecure" certificates. Let me check if I either put a dedicated checkbox in - or find a flexible way to add curloptions in general on demand. This might even be more future prove if some other requirements come up

tautomer@c99970d
I'm trying to add an option to the $template array (mimicking what you have done). But with the dropdown list, no matter which one I choose, VERIFYHOST is disabled. Not sure what is wrong.

[tautomer]

Got it working by changing the actual option to 0 and 2, instead of true or false.

2 to verify that a Common Name field or a Subject Alternate Name field in the SSL peer certificate matches the provided hostname. 0 to not check the names. 1 should not be used. 

Because of this, using true/false will not work, as only 0 is a valid option. 1 just throws an error, rendering the line useless.

master...tautomer:analytics:allow_insecure

Now it looks like this.

Defaults to No. Yes is 0 and No is 2 for VERIFYHOST. Changing the option to No will instantly return a code 0.

But I'm sure you can come up with a better option. However, if you want, I can create a PR to save you some effort.