Loxone API - Fetch API cannot load [...] due to access control checks.

[MarkusCosi]

Hallo,

bei einem Projekt nutze ich die Loxone json API, siehe hier.

D.h. mit einer basic authentication greife ich vom Miniserver Daten ab, e.g. in der erstellten index.html im JavaScript-Teil via:

fetch(http://<<IP Miniserver>>/jdev/sps/io/1ae2d1c5-XXX-XXXX-YYYY/state, {
headers: {
'Authorization': 'Basic ' + authString}
})

Das klappt soweit, jedoch nur wenn ich nach je 6 requests einen Timeout einbaue (e.g. "setTimeout(Function mit je 6 fetchData()-Aufrufen, 5000);") und 5 - 40 sek warte bis zur nächsten "Anfragen-Runde".
Tue ich das nicht, so kommt eine Reihe von Fehlermeldungen in der JavaScript Console des Safari Browsers:

- [Error] Fetch API cannot load http://<<IP Miniserver>>/jdev/sps/io/1ae2d1c5-XXX-XXXX-ffff4865a4527a1d/state due to access control checks.

Das Verhalten spiegelt sich auf einem iPad / iPhone. Beim Mac kann ich das mit dem Firefox-Browser umgehen, hab dann aber andere Probleme. Gern möchte ich das was ich tue nativ im Safari machen.

Das ganze scheint mit den Browser-eigenen CORS (cross-origin ressource sharing) Einstellungen zu tun zu haben, siehe hier. D.h., der Loxone Miniserver scheint CORS-Einstellungen gesetzt zu haben, die von Safari so ausgelegt werden, dass nur eine begrenzte Zahl von Abrufen erlaubt wird? So ganz verstehe ich das eigentlich nicht, da ich diese CORS Beschränkungen nur als Digital (Ja/Nein), nicht als Frequenz / Anzahl-Beschränkungen verstanden habe... Jedenfalls scheint das nur Server-Seitig behebbar zu sein?

Beim Safari kann ich das lösen über die Developer-Tools → Developer Settings → Security → disable local file restrictions (siehe hier). Beim iPad leider nicht, bzw. nur etwas kompliziert über USB und nur einmalig (siehe hier). Das ganze ist aber fürs iPad eigentlich gedacht, daher sollte es insbesondere dort funktionieren.

Hatte jemand schonmal dieses Problem und weiß wie man damit am besten umgeht?

Danke!

[Christian Fenzl]

Ehrlich gesagt ist es ein Wunder, dass da überhaupt etwas zurück kommt. Die Same-Origin-Policy müsste das komplett verhindern.

Wenn du die Werte serverseitig vom MS abrufst, statt direkt im JS den MS abzurufen, dann hast du keine Probleme.

lg, Christian

[MarkusCosi]

vielen Dank, Christian, für die Rückmeldung!

Wie genau würde das denn aussehen? Ein Skript auf dem LoxBerry welches in der index.html aufgerufen würde? Gerne würde ich die Daten ja nur bei Bedarf, d.h. nur bei Anzeige / Abruf der gebastelten index.html abfragen lassen. Könntest du mich auf ein Beispiel verweisen an dem ich mich orientieren könnte?

Alternativ dachte ich in Richtung anderer Authentifizierungsmethoden. Hätte das Aussicht auf Erfolg? Leider finde ich die Dokumentation "COMMUNICATING WITH
THE LOXONE MINISERVER" unter https://www.loxone.com/enen/kb/api/ nicht nachvollziehbar. Der Step-by-Step guide ab Seite 8 enthält so viele Punkte an denen ich kA habe wie ich vorzugehen hätte, dass es mir als Laien unmöglich scheint das umzusetzen. Gibt es noch Mittelwege? Tokens? Gäbe es hier ein Beispiel an dem ich mich orientieren könnte?

Danke!

[Christian Fenzl]

<?php
require_once "loxberry_XL.php";
header('Content-Type: application/json; charset=utf-8');
echo json_encode( array('name'=>$ms1->get($_GET['name'])));

Das legst du z.B. in /opt/loxberry/html/legacy/getvalue.php
chmod +x /opt/loxberry/html/legacy/getvalue.php
und rufst es (erstmal) im Browser ab per:
http://loxberry/legacy/getvalue.php?name=Außentemperatursensor

Da sollte nur das json zurückkommen - wenns geht, kannst du das in deinem HTML fetchen.

lg, Christian

PS: Komischerweise kommt bei meinem LoxBerry nicht nur json, sondern auch ein Debug-Output zurück, aber das könnte ein spezifisches Problem meiner VM sein.

[MarkusCosi]

Danke, das werde ich mal probieren! der "name" im Aufruf an das getvalue.php-Skript ist die uuid? Oder muss das eine eindeutige Bezeichnung sein? (ich fürchte die habe ich aktuell noch nicht bei allen Temperatursensoren/werten) Könnte man dann auch alternativ per uuid abfragen? Danke!

[MarkusCosi]

es funktioniert, danke!

ich habe das Skript (ergänzt um ?>) über den Loxberry filemanager unter "/opt/loxberry/webfrontend/html/XL/user" abgelegt. Ein Aufruf klappt mit dem Parameter "<<SkriptPath>>?name=uuid". Es kommen jedoch 2 Zeilen zurück statt einem json, z.B. 1. Zeile = "Responseval: 11.8° Respcode: 200" und 2. Zeile etwas, was nach json aussieht: {"name":"11.8\u00b0"}". Leider kam mein java script damit so nicht ohne Änderungen klar, da es einfach nur ein json erwartet.. Ich habe den code daher abgeändert und nutze nun statt dem .json() des response einfach den Text und parse diesen: d.h. ich nutze: .then((response) => response.text())
.then((text) => {
text = text.substring(text.indexOf("val:") + 5);
text = text.substring(0, text.indexOf("°"));
const value = text;
....

[Christian Fenzl]

Ich dachte erst, das mit der Zeile wäre ein Problem bei mir, aber es ist ein Fehler in meinem io-Library-Code:

https://github.com/mschlenstedt/Loxberry/blob/5b9f4f30d12aa181affbd70a35a9d4d0d4d39b37/libs/phplib/loxberry_io.php#L286

Das Echo muss auskommentiert werden. I’m LoxBerry Master hab ich’s schon behoben.

lg Christian

PS: Das heißt allerdings, beim nächsten LBUpdate ist die Zeile, die nicht json ist, weg! Du solltest es bei dir manuell korrigieren und dann das json nutzen.

[MarkusCosi]

alles klar, da bin ich vorgewarnt und wundere mich nicht, danke .. Das passe ich dann an wenn es soweit ist.