Closed opal06 closed 1 year ago
Die Überprüfung der URL geschieht immer auf die gleiche Art, auf die später auf die URL zugegriffen wird. Alles andere würde auch keinen Sinn machen. Schliesslich soll die Überprüfung ja testen, ob Nightscout Reporter die URL verwenden kann. So wie es aussieht, ist die Seite durch Authentifizierung geschützt, weshalb dort ein Token gesetzt werden muss. Du kannst sowas eigentlich nur dann zuverlässig testen, wenn Du auf Deinen Server von ausserhalb Deines Netzwerkes zugreifst, wie das auch Nightscout Reporter macht.
In Deinem Fall sollte das dann über https://nightscout.flserver.net/api/v1/status.json?token=xxx geschehen, wobei xxx das Token ist. Du hast das zwar aus dem Listing oben entfernt, aber die Authentication Antwort vom Cloudflare Server inklusive der Autorisierungsantwort steht drin. Keine Ahnung, ob ein Hacker was damit anfangen kann (ich bin keiner), aber die Info würde ich an Deiner Stelle auch nicht so öffentlich verteilen. Da wäre das Token schon etwas weniger sicherheitsrelevant, denke ich.
Zur Authentifizierung verwende ich einen in Nightscout generierten Token mit den Berechtigungen ::read, was auch erfolgreich funktioniert, nachdem ich die erste Einrichtung des Reporters ohne Cloudflare-Proxy vorgenommen habe. Es scheint nur bei der erstmaligen Einrichtung auf einem neuen Gerät (oder nach Löschen der Websiten-Daten) nicht zu funktionieren. Den Token zu entfernen war in der Tat vlt. etwas übereifrig. Jedenfalls kann ich bestätigen, dass ich von außerhalb meines Heimnetzes mit diesem Token die status.json-Datei aus meinem ersten Post abrufen konnte. Du kannst es gerne selbst überprüfen, hier wäre die URL, diesmal mit Token: https://nightscout.flserver.net/api/v1/status.json?token=nightscout-4616e25f9249f0e3
Ich bin mir aber auch bewusst, dass es vlt. ein edge-case ist, der nicht unbedingt gefixt werden muss. Es gibt ja immerhin einen Workaround...
Was Cloudflare angeht, danke für den Hinweis. Habe den jetzt sicherheitshalber entfernt, wobei ich nicht sicher bin, auch wenn das nur mit Cloudflares Network Error Reporting zu tun haben sollte.
Ich hoste Nightscout auf einer Domain von Cloudflare. Traffic wird über Cloudflares Proxy geleitet. In diesem Szenario meldet Nightscout-Reporter direkt eine unerreichbare URL, obwohl die Domain erreichbar ist (auch über den Button im Reporter selbst neben dem URL-Eingabefeld; der Token ist also korrekt). CORS ist ebenfalls aktiviert (siehe status.json). Mit deaktiviertem Proxy (Cloudflare nur als DNS-Provider für die Domain) ist die Nightscout-URL für den Reporter erreichbar. Sobald die URL einmal gespeichert und "gefunden" wurde, funktioniert die Datenabfrage dann aber auch über den Cloudflare-Proxy. Insofern scheint es ein konkretes Problem bei der ersten Überprüfung der URL zu sein.
Ich füge hier den Output der status.json-Datei an sowie den HTTP-Response-Header mit und ohne Cloudflare-Proxy:
status.json:
HTTP-Response-Header mit Cloudflare:
HTTP-Response-Header ohne Cloudflare: