Access-Control-Allow-Origin ist bei Version 2.0 fehlerhaft
Gerti1972 opened this issue · 11 comments
Wenn ich von einer anderen IP auf die Version 2.0 der XML-Api zugreifen möchte, kommt eine Fehlermeldung.
Access to XMLHttpRequest at 'http://192.168.2.126/config/xmlapi/state.cgi?datapoint_id=10992,11281,3302,67298&sid=@TECCuChI81@' from origin 'http://192.168.2.20:8992' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Soweit ich mich dazu belesen habe, kann diese Problem nur auf Seiten der XML-Api gelöst werden, nicht Clientseitig.
Mit der bisherigen 1.x Version gibt es hier keine solche Einschränkung.
In der Tat sind in der v1 der XML-API folgende Access-Control-Allow-Origin: Header Einträge standardmäßig hinzugefügt um solche cross-origin zugriffe generell von allen Stellen zu erlauben. Siehe:
Line 4 in a701c57
Das "Problem" hierbei ist jedoch, das bei einem solchen generellen * erlauben von cross-origin aufrufen der XML-API dies ein potentielles Sicherheitsrisiko darstellt. Es kann nämlich dann passieren, das auf einer fremden Webseite versteckte XMLHTTPRequests versteckt werden die wiederum im Kontext des Webbrowsers versuchen die XML-API Remote abzufragen. Deshalb habe ich mich bei dem redesign der v2 XML-API dazu entschieden dieses generelle Abschalten der CORS policy zu entfernen da die v2 ja vor allem einen Sicherheitsgewinn mit sich bringen soll.
Die Frage wäre also warum bzw. wie genau diese XMLHTTPRequest aufrufe bei dir im Browser Kontext stattfinden und warum diese in diesme Kontext stattfinden müssen und nicht in einem anderen Kontext (z.B. direkt auf einem System, node.js, etc.). Um Welche Applikation handelt es sich da also?
Es handelt sich um Homehub, dass lokal im Netzwerk auf einem Server läuft. Die Aufrufe erfolgen per PHP bzw. Javascript.
Ich habe eine Webseite (public) die aktuell per https auf die ccu (per 192.168.0.x) zugreift.
Die grobe infrastruktur würde ich gerne behalten.
Man könnte in der xml-api config urls eingeben, die dann in den origin header gingen.
So ähnlich macht das auch die Fritzbox:
Ich denke auch, dass es wohl irgendwie konfigurierbar sein müsste oder ggf. die Regeln der internen Firewall einfach verwendet werden. Dort kann ich ja meinen Adressbereich zulassen.
Mit Firewall hat das streng genommen nichts zu tun. Man bräuchte eben eine Konfigurationsmöglichkeit dieser Origin (CORS) Header wenn man schon unbedingt solche Dinge im Webbrowser-Kontext ablaufen lassen will (wovon ich allerdings unabhängig hiervon generell abraten würde). Und eigentlich gehört so etwas in die generelle WebUI und jetzt nicht in jedes Addon das möglicherweise APIs wie doe XML-API nach außen zur Verfügung stellen möchte. Auch kenne ich "HomeHub" nicht (noch nie davon gehört) und kann daher nichts dazu sagen ob es auch noch andere Wege gäbe das selbe auf anderem/sicheren Wege zu ermöglichen.
Das bedeutet dann also, das hier entweder eQ3 aktiv werden müsste/sollte um diese Origin/CORS Header Nutzer konfigurierbar zu machen oder das dann eben ein RaspberryMatic only Feature wird. Jetzt der XMLAPI noch eine eigene Konfigurationsoberfläche dafür zu spendieren würde vmtl einfach zu weit gehen.
Das du von homehub noch nie gehört hast, wundert mich etwas. Gab es schon Vorträge auf den Usertreffen zu.
Die Weiterentwicklung von Homehub habe ich von Braindead übernommen und passe eigentlich nur das Frontend an, füge neue Komponenten hinzu und halte es immer noch für eine der einfachsten und trotzdem optisch ansprechendsten Visualisierungen (auch wenn das sicher Geschmacksache ist).
Hier ein Video dazu: https://www.youtube.com/watch?v=8njvl4UDhF0
Hier der Link im Forum: https://homematic-forum.de/forum/viewtopic.php?f=41&t=76034
Ich habe das Backend jetzt soweit angepasst, dass die sid erzeugt und verwendet wird, das Aktualisieren der Daten erfolgt aber über ein Javascript im Browser, was durchaus keine ungewöhnliche Methode ist.
Wenn man es für die XML-Api nicht in der WebUI konfigurierbar machen möchte, dann doch aber bitte über eine config-Datei, in der man das einmalig hinterlegen kann.
wenn man schon unbedingt solche Dinge im Webbrowser-Kontext ablaufen lassen will (wovon ich allerdings unabhängig hiervon generell abraten würde).
Hab mir eine Progressive Web App (PWA) gebaut. Damit hab ich Homescreen Icon und visuell wenig Unterschied zu einer nativen App.
Ich denke, ich konnte es für Homehub lösen, indem ich ein Interface gebastelt habe, dass die Daten per PHP abholt und dem Javascript zur Verfügung stellt.
Ich denke, ich konnte es für Homehub lösen, indem ich ein Interface gebastelt habe, dass die Daten per PHP abholt und dem Javascript zur Verfügung stellt.
So wollte ich das auch bereits vorschlagen als den IMHO besseren Ansatz. Einfach die Daten im PHP Kontext aholen+bearbeiten und einfach nur via Javascript darstellen lassen. Somit ist das ganze dann auch noch wesentlich Browsertyp-unabhängiger.
Aber gut, ich verstehe die grundsätzliche Problematik und das man ggf. für das setzen der Origin: header irgendeine Lösung bräuchte wenn man das in der v2 auf sicherem Weg unterstützen will. Noch aber habe ich keine Konkrete Idee wie man das am besten/variabelsten umsetzen könnte.
So wollte ich das auch bereits vorschlagen als den IMHO besseren Ansatz. Einfach die Daten im PHP Kontext abholen+bearbeiten und einfach nur via Javascript darstellen lassen.
Besserer Ansatz?
- Webseite irgendwo hosten lassen und per JS auf interne ccu zugreifen. Geht nur im internen Netz (oder vpn). Security-mässig trivial und keine erhöhte System-Komplexität.
- Webseite hosten, so dass das php auf das interne Netz zugreifen kann. Ist diese Seite extern zugreifbar hat man Zugriff von überall auf die ccu. Urghs. Und man hat erhöhte System-Komplexität.
- Webseite hosten, so dass das php auf das interne Netz zugreifen kann. Per Passwort-Schutz im PHP. Ist das sicher und fehlerfrei implementiert? Und man hat erhöhte System-Komplexität.
So wollte ich das auch bereits vorschlagen als den IMHO besseren Ansatz. Einfach die Daten im PHP Kontext abholen+bearbeiten und einfach nur via Javascript darstellen lassen.
Besserer Ansatz?
Falscher Platz um sich zu streiten. Es ist so wie es ist bzw. wie es wird für die v2. CORS policies sind nicht zum spass da und diese generell auf * ist IMHO keine gute Idee. Also entweder Art der Abfrage/Nutzung der XML-API v2 ändern, bei der XML-API v1 bleiben oder darauf warten das ich oder jemands anders etwas implementiert um die Origin: Header zu setzen. Generell diese auf * zu setzen wird definitiv nicht zurückkommen in die v2.