Hallo Rolf herzlichen Dank für Deine umfassende und erhellende Beschreibung! Habe mich sehr gefreut so schnell eine Antwort zu bekommen !! Ich habe einen Kurs PHP I besucht, PHP II läuft gerade (zweite von vier Wochen). Leider ohne Vorkenntnisse von HTML und CSS, was den Kurs nicht gerade leicht für mich macht, aber es geht schon irgendwie.. Ich verstehe jedenfalls, was Du mir hier beschreibst, vielen Dank nochmal für Deine Mühe! > Hallo Sigi, > .... > Der Server, der auf 192.168.2.35 am Port 80 auf http Anfragen lauscht, hat nun die Aufgabe, aus der Ressourcenabfrage > > /command?code=19082401000900000100E0587D0101000100000000000100000000&XC_FNC=Send2 > > etwas zu machen. Ein klassischer Webserver versucht, Ressourcenabfragen auf Dateien abzubilden, die er dann ausliefert oder - beispielsweise bei PHP Scripten - ausführt .... > > Das muss das Mediola Gateway aber nicht zwingend tun. Es bekommt einfach diese Zeichenkette /command...Send2 und darf sie nach Laune interpretieren. Es darf sich an die Regeln für URIs halten, sollte das auch, muss aber nicht. Abfragen wie > > http://192.168.2.35/bitte_schalte_den_fernseher_aus > http://192.168.2.35/bitte_mach_den_ton_etwas_leiser > > könnte man durchaus ebenfalls zulassen. .... Die Schnittstelle zum Gateway benutzt direkt die Infrarot-Codes, so das das Gateway gar nicht weiss, was es damit auslöst, und keine weitere Konfiguration hinterlegt ist, verstehe aber was Du meinst. > Die Benutzererfahrung ist da aber nicht so gut. Die Folge eines solchen Links dürfte ein leerer Bildschirm sein, oder einer, der fast leer ist und auf dem nur noch "ok" steht. Ja, das war wohl bisher das Problem mit dem Button, das Gateway liefert keine Antwort > > Schöner geht das mit JavaScript. .... >Der Browser kann nämlich nicht zwischen deiner Mediola-Steuerung und einer bösen Seite unterscheiden, die dein Bankkonto plündern will. auch klar > Die einzige Möglichkeit, die ich kenne, um das zu umgehen, ist ein spezieller Aufruf mit dem fetch-API, dem Du den mode-Parameter auf "no-cors" setzt. Der Aufruf wird dann durchgeführt, aber du bekommst auf dem Weg keine Daten. > > ~~~js > fetch("http://192.168.2.35/command?...Send2", { mode: "no-cors" }); > ~~~ > Das CORS Konzept setzt eine aktive Mitwirkung der aufgerufenen Seite voraus (also das Mediola Gateway) .... Das Gateway wird normalerweise über ein APP bedient, und liefert nichts zurück, soweit ich es bisher herausgefunden habe. Wenn man eine neue Version der APP installiert, muss man nur alles neu konfigurieren, ausserdem läuft die APp nicht auf jedem Device. UNd es ist eine gute Übung zum Programmieren und für das Verständnis... > > Eine andere Alternative ist ein Webserver mit PHP im gleichen Netz wie das Mediola Gateway, von dem Du deine Seite lädst. Deine Seite kann mit AJAX Techniken Requests an PHP Scripte auf dem Webserver schicken, und die leiten die Aufrufe nach Mediola durch. An der Stelle hast Du keine XSS Sperre mehr. Auf die letztgenannte Lösung wird es wohl, angesichts meines aktuell laufenden PHP Kurses, hinauslaufen. Dazu habe ich auch gleich noch eine Frage: Das PHP Script kann doch auch direkt vom Button aufgerufen werden, (habe ich noch nicht gemacht) läuft dann auf dem Server und kann den Befehl dann direkt an das Gateway absetzen, oder wird das auch vom Browser überwacht? Kann doch eigentlich nicht sein, weil der Code des Buttons auf dem Webserver abläuft, ausserhalb des Browser Zugriffs?!? (Die Page mit dem Button stellt der Webserver auf der Synology im selben Netz zur Verfügung) Würde es dann reichen, einfach eine Datei auf das Gateway zu schreiben, ab "command" (einschliesslich), oder welcher Befehl wäre hierfür sinnvoll / zielführend? Ich verstehe das schon relativ gut, aber habe auf dem Gebiet noch viel zu wenig Erfahrung.(> 20 Jahre Softwareentwicklung, aber auf einem anderen Gebiet, Visual Basic, früher mal C). Viele Grüße Sigi

HAllo Rol herzlichen Dank für Deine umfassende und erhellende Beschreibung! Habe mich sehr gefreut so schnell eine Antwort zu bekommen !! Ich habe einen Kurs PHP I besucht, PHP II läuft gerade (zweite von vier Wochen). Leider ohne Vorkenntnisse von HTML und CSS, was den Kurs nicht gerade leicht für mich macht, aber es geht schon irgendwie.. Ich verstehe jedenfalls, was Du mir hier beschreibst, vielen Dank nochmal für Deine Mühe! > Hallo Sigi, > .... > Der Server, der auf 192.168.2.35 am Port 80 auf http Anfragen lauscht, hat nun die Aufgabe, aus der Ressourcenabfrage > > /command?code=19082401000900000100E0587D0101000100000000000100000000&XC_FNC=Send2 > > etwas zu machen. Ein klassischer Webserver versucht, Ressourcenabfragen auf Dateien abzubilden, die er dann ausliefert oder - beispielsweise bei PHP Scripten - ausführt .... > > Das muss das Mediola Gateway aber nicht zwingend tun. Es bekommt einfach diese Zeichenkette /command...Send2 und darf sie nach Laune interpretieren. Es darf sich an die Regeln für URIs halten, sollte das auch, muss aber nicht. Abfragen wie > > http://192.168.2.35/bitte_schalte_den_fernseher_aus > http://192.168.2.35/bitte_mach_den_ton_etwas_leiser > > könnte man durchaus ebenfalls zulassen. .... Die Schnittstelle zum Gateway benutzt direkt die Infrarot-Codes, so das das Gateway gar nicht weiss, was es damit auslöst, und keine weitere Konfiguration hinterlegt ist, verstehe aber was Du meinst. > Die Benutzererfahrung ist da aber nicht so gut. Die Folge eines solchen Links dürfte ein leerer Bildschirm sein, oder einer, der fast leer ist und auf dem nur noch "ok" steht. Ja, das war wohl bisher das Problem mit dem Button, das Gateway liefert keine Antwort > > Schöner geht das mit JavaScript. .... >Der Browser kann nämlich nicht zwischen deiner Mediola-Steuerung und einer bösen Seite unterscheiden, die dein Bankkonto plündern will. auch klar > Die einzige Möglichkeit, die ich kenne, um das zu umgehen, ist ein spezieller Aufruf mit dem fetch-API, dem Du den mode-Parameter auf "no-cors" setzt. Der Aufruf wird dann durchgeführt, aber du bekommst auf dem Weg keine Daten. > > ~~~js > fetch("http://192.168.2.35/command?...Send2", { mode: "no-cors" }); > ~~~ > Das CORS Konzept setzt eine aktive Mitwirkung der aufgerufenen Seite voraus (also das Mediola Gateway) .... Das Gateway wird normalerweise über ein APP bedient, und liefert nichts zurück, soweit ich es bisher herausgefunden habe. Wenn man eine neue Version der APP installiert, muss man nur alles neu konfigurieren, ausserdem läuft die APp nicht auf jedem Device. UNd es ist eine gute Übung zum Programmieren und für das Verständnis... > > Eine andere Alternative ist ein Webserver mit PHP im gleichen Netz wie das Mediola Gateway, von dem Du deine Seite lädst. Deine Seite kann mit AJAX Techniken Requests an PHP Scripte auf dem Webserver schicken, und die leiten die Aufrufe nach Mediola durch. An der Stelle hast Du keine XSS Sperre mehr. Auf die letztgenannte Lösung wird es wohl, angesichts meines aktuell laufenden PHP Kurses, hinauslaufen. Dazu habe ich auch gleich noch eine Frage: Das PHP Script kann doch auch direkt vom Button aufgerufen werden, (habe ich noch nicht gemacht) läuft dann auf dem Server und kann den Befehl dann direkt an das Gateway absetzen, oder wird das auch vom Browser überwacht? Kann doch eigentlich nicht sein, weil der Code des Buttons auf dem Webserver abläuft, ausserhalb des Browser Zugriffs?!? (Die Page mit dem Button stellt der Webserver auf der Synology im selben Netz zur Verfügung) Würde es dann reichen, einfach eine Datei auf das Gateway zu schreiben, ab "command" (einschliesslich), oder welcher Befehl wäre hierfür sinnvoll / zielführend? Ich verstehe das schon relativ gut, aber habe auf dem Gebiet noch viel zu wenig Erfahrung.(> 20 Jahre Softwareentwicklung, aber auf einem anderen Gebiet, Visual Basic, früher mal C). Viele Grüße Sigi