Authentication for uptime monitoring services

Hi,

I wanted to confirm how to authenticate for uptime services such as UptimeRobot or Pingdom.

Concretely, I am trying to have the service (UptimeRobot) check the url “/hq/admin/system/check_services” and check for a keyword.

My tests show that authentication fails with HTTP Basic and Digest (the service gets redirected to the ‘403 No Permissions’ page). I am using the username/password of the super admin server user.

Could you please confirm what authentication protocol and user I should be using ? Or anything else I am doing wrong.

Thanks!

Guillaume

#IT4LIFE

Adding the log of an attempt to get the content of the ‘check_services’ page using curl and basic auth:

*   Trying 178.170.46.8:443...
* TCP_NODELAY set
* Connected to si-imyeta.gret.org (178.170.46.8) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=si-imyeta.gret.org
*  start date: Jul  3 09:13:20 2020 GMT
*  expire date: Oct  1 09:13:20 2020 GMT
*  subjectAltName: host "si-imyeta.gret.org" matched cert's "si-imyeta.gret.org"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Server auth using Basic with user 'support@it4life.org'
* Using Stream ID: 1 (easy handle 0x55e5b5a17db0)
> GET /hq/admin/system/check_services HTTP/2
> Host: si-imyeta.gret.org
> authorization: Basic c3VwcG9ydEBpdDRsaWZlLm9yZzpjY2hxQEdSRVRASVQ0TElGRQ==
> user-agent: curl/7.68.0
> accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 302 
< server: nginx
< date: Fri, 11 Sep 2020 22:50:56 GMT
< content-type: text/html; charset=utf-8
< content-length: 0
< location: /no_permissions/
< http_x_openrosa_version: 1.0
< x-frame-options: SAMEORIGIN
< vary: Accept-Language, Cookie
< content-language: en
< cache-control: private, no-cache, no-store, must-revalidate, proxy-revalidate
< expires: Thu, 01 Dec 1994 16:00:00 GMT
< pragma: no-cache
< 
* Connection #0 to host si-imyeta.gret.org left intact

The return code is 302 and the request gets redirected to the ‘/no_permissions/’ page.

Hey Guillaume,

I cannot speak to the specific endpoint you are describing, but we run our uptime checks against /serverup.txt which does not require any authentication, and will return a 200 status code with the body “success” if all services are up, and a 500 status code otherwise with the details of which service is down. The format of the 500 response is the same as the /hq/admin/system/check_services output but only includes the services that failed the check rather than all of them.

Cal

Thanks Cal. This works.