Tablet UI auf Apache Webserver

[michael.schefczyk]

Könnte jemand bitte so freundlich sein, mir Starthilfe dabei zu geben, wie man Tablet UI auf einem separaten Apache Webserver betreiben kann? Eine funktionierende Konfiguration von Tablet UI habe ich auf einem FHEM Server erstellt. Allerdings möchte ich diese auf einen separaten Webserver verlagern, der mit dem FHEM Server kommuniziert. Mein naiver Gedanke war, dass man eine Zeile im Sinne von

<meta name='fhemweb_url' content='192.168.1.XXX:8083/fhem/'>

in die index.html-Datei eintragen müsste, um das Ziel zu erreichen.

Eine solche separate Installation bekomme ich allerdings leider nicht zum Laufen. Dies funktioniert nicht auf einem Debian 9 Virtualmin Server mit Apache und zahlreichen php-Modulen einschließlich php-json. Es ist nicht nur so, dass der Datenaustausch mit dem FHEM Server nicht funktioniert. Auch ftui_check.html zeigt nur leere Rahmen. Das apache error log bleibt ebenfalls leer. Die gleiche Situation entsteht, wenn man Tablet UI versuchsweise auf einem Windows PC mit XAMPP installiert.

Die meisten Antworten zu Fragen dieser Art stammen aus 2015/2016 (z. B. https://forum.fhem.de/index.php/topic,38764.msg309390.html#msg309390 ). Ist man noch auf dem Stand, dass man auch beim externen Server nicht lediglich Tablet UI auf Apache betreiben muss, so dass man einen beliebigen Webserver verwenden kann, sondern noch einmal den gesamten FHEM Unterbau benötigt - also eben nicht jeden Apache-Webserver einfach mitverwenden kann?

[Waldmensch]

Das ist auch weiterhin so, da nur FHEM die Daten von FHEM hat und Events nun mal durch den Websocket schiebt. Wo sollen denn Deiner Meinung nach die Events auf dem Apache generiert werden?



Gesendet von iPhone mit Tapatalk

[amenomade]

Das ist auch weiterhin so, da nur FHEM die Daten von FHEM hat und Events nun mal durch den Websocket schiebt. Wo sollen denn Deiner Meinung nach die Events auf dem Apache generiert werden?

Genauso wie auf dem httpsrv von Fhem: mit HTML/Javascript
Die TabletUI Seiten rufen natürlich im Hintergrund Fhem

[amenomade]

@michael: es gibt mehrere andere Threads darüber. Z.B.
https://forum.fhem.de/index.php/topic,78156.msg701882.html#msg701882
https://forum.fhem.de/index.php/topic,55132.msg470824.html#msg470824
https://forum.fhem.de/index.php/topic,38764.msg309390.html#msg309390

[Waldmensch]

Aha, und wer sagt dem Apache, dass er jetzt  das Event ,,dummy1 on" für den clientbrowser pushen soll?

Edit: oder redest Du von einem simplen Reverse Proxy?

Gesendet von iPhone mit Tapatalk

[Thorsten Pferdekaemper]

Hi,

ich verstehe momentan nicht so ganz die Problematik. Im Endeffekt kommuniziert ja der Browser direkt mit FHEM. Wie die Seiten zum Browser kommen ist erst einmal fast egal, zumindest wenn man (zumindest versuchsweise) die ganzen Sicherheitsmechanismen abschaltet, wie das CORS bzw. csrf-Attribut (ich weiß gerade aus dem Kopf nicht, wie die genau heißen).
Natürlich muss der FHEM-Server vom Browser aus (nicht unbedingt vom Webserver aus) erreichbar sein. User und Passwort müssen dann ebenfalls irgendwie mitgegeben werden oder eben in der FHEMWEB-Instanz abgeschaltet.
Außerdem müssen auch alle FTUI-Dateien auf dem Webserver liegen.

Wenn Du willst, dass alles durch den Webserver läuft, dann brauchst Du tatsächlich die Einstellung als "reverse proxy", wie schon angedeutet. Das hat dann aber nichts mit der fhemweb_url-Meta-Angabe zu tun, da ja die FTUI-Seiten "glauben" sollen, dass die auf den Webserver zugreifen, und nicht direkt auf FHEM.


Gruß,
   Thorsten

[amenomade]

Aha, und wer sagt dem Apache, dass er jetzt  das Event ,,dummy1 on" für den clientbrowser pushen soll?

Edit: oder redest Du von einem simplen Reverse Proxy?

Gesendet von iPhone mit Tapatalk

Ja, Reverse Proxy wegen Fhem Verbindung, und Webserver für die HTML FTUI Seiten

[Waldmensch]

Und was ist der Sinn dahinter? Die HTML Seiten werden doch im Optimalfall nur einmal übertragen. Für den Rest muss FHEM eh ackern, ob da nun noch ein Proxy dazwischenklemmt oder nicht. Die einzige sinnvolle Anwendung, die ich für einen Reverse Proxy kenne, ist, mehrere HTTP Services, die auf unterschiedlichen Ports laufen, auf einem Server zu konsolidieren.

Die Hardware für einen zusätzlichen Apache würde ich eher zum Aufstocken der FHEM Instanz verwenden, um beispielsweise eine Mariadb drunterzupacken. Das verleiht schon mal ordentlich Flügel.


Gesendet von iPhone mit Tapatalk

[amenomade]

Und was ist der Sinn dahinter?

Ich weiss nicht, was der TE damit machen will. Ich selbst mache sowas nicht.
Aber man kann sich andere Benutzungen überlegen: den Webserver anders schützen (z.B. mit .htaccess), Weboberfläsche mit anderen Sachen integrieren, den Webserver vom Fhem Server anders trennen, einen anderen Authentifizierungsmechanismus benutzen, irgendwelches rewrite implementieren, usw... Oder wenn man schon ein im Internet freigegebenen Apache hat, und nicht zu viele Ports freigeben will...

Mit Apache kann man schon viel mehr machen als mit dem simplen httpsrv von Fhem.

Natürlich macht es wenig Sinn für jemanden, der nicht genau weiss, was er mit seinem Apache macht. Weil man mit Apache auch viel Unsinn / viele (zusätzliche) Sicherheitslücken bauen kann. Lieber kein Apache als ein schlecht konfiguriertes Apache

[michael.schefczyk]

Danke! Meine Situation ist so, dass bei Funksensoren (z. B. Thermo/Hydro) die Funkreichweite begrenzt ist. Außerdem haben wir zwei Wohnungs- und Bürosituationen. Im Ergebnis habe ich  bisher an zwei Stellen ohne Funk (Heizkörperthermostate über einen Cube einerseits und Hue-Leuchten andererseits, einen FHEM-Server auf einer virtuellen Maschine. An einer dritten Stelle habe ich einen PCEngines APU2 mit FHEM, um mit einem USB-Stick Funksensoren aufzunehmen. Es wäre gut, wenn man alles in einer Weboberfläche integrieren könnte. Ganz ideal wäre es, wenn man dafür nicht noch einmal FHEM installieren müsste, sondern nur TabletUI auf einem (schon bestehenden und mit vielen relevanten Sicherheitsfeatures ausgetatteten) Webserver. Gemeinsam mit anderen Webseiten könnten man dann leicht eine sichere Authentifizierung für Nutzer durchführen, z. B. mit Client-Zertifikaten.

Danke an @amenomade für die Hinweise auf die drei Threads. Der dritte stand schon in meiner Frage und schien nicht zu helfen. Die andern beiden klopfe ich noch einmal genau ab.

Wichtig war und ist mir aber zu verstehen, ob es überhaupt möglich ist TabletUI ohne den kompletten FHEM-Unterbau zu betreiben. Meine Gründe sind nun hoffentlich etwas klarer. Ich möchte zur Integration keine simple Reverse Proxy, sondern den guten optischen Eindruck von TabletUI für die Daten aller (derzeit drei) FHEM-Installationen/Standorte auf einen Blick. Der Webserver mit (gewünschtem) TabletUI kann im LAN/VPN natürlich mit allen FHEM-Servern kommunizieren. Ein eigenes Smartphone im WAN sollte mit dem Webserver/TabletUI kommunizieren können, aber schon aus Sicherheitsgründen nicht direkt mit den mehreren FHEM-Servern im LAN.

[amenomade]

Wie schützt Du aber den Zugriff zu fhemweb, wenn Apache nicht als Reverse Proxy für fhem steht?

Anyway... damit es funktionieren kann, musst Du mindestens, wie Thorsten hieroben geschrieben hat, attr CORS 1 setzen, und csrf_token fix machen oder deaktivieren.