FTUI 2.6

[setstate]

Bei Readingsgroup habe ich den csrfToken noch nicht eingebaut.

FHEM lehnt damit jegliche Anfragen ab.

[klausw]

Für longpoll setzte ich keinen automatischen Filter. Longpoll wird schon gestartet, bevor alle Subscriptions eingesammelt wurden. Ich könnte es jedesmal neu starten () ...

Der Metatag ist auch nicht verkehrt. Man könnte ja ein eigenes attribut anlegen, das für jedes Device was ins FTUI soll gesettz wird. Aber dann werden immer noch alle Redings dieser Devices gepushed, oder?

Wenn das mit dem neu starten sich einbauen lässt ist das sicher eine komfortablere Lösung.

So oder so wird damit einiges an Traffic rausgenommen.

[klausw]

Ist es möglich das simplechart nicht mehr unter 2.6 läuft?
Ich bekomme nur leere Diagramme, chart funktioniert aber.
csrfToken ist bei mir deaktiviert

[setstate]

Nö, geht bei mir auch mit csrf.

[grossmaggul]

Verstehe ich mal wieder was nicht?

Ich habe in der index.html das hier entkommentiert

Code Auswählen Erweitern

<link rel="stylesheet" href="css/fhem-green-ui.css" />

In meiner naiven Vorstellung bin ich davon ausgegangen, daß dies die Farben der Tablet UI ändert, da tut sich aber rein gar nix.

Muß man da noch was entkommentieren?

[ext23]

Ich bin dran. Bitte kein Update ziehen derzeit.

Läuft wieder, danke! (Das mit der re-auth nach einigen Minuten)

/Daniel

[klausw]

Nö, geht bei mir auch mit csrf.

Habe nochmal ein bisschen rumprobiert:
Über die HTTPSRV Variante funktioniert es. Die Werte werden angezeigt.
Über Apache allerdings nicht (es ist die gleiche html Datei)
Die Verzeichnisstruktur ist auch identisch:
host.ip/pgm2
host.ip/tablet
host.ip/tablet/css
host.ip/tablet/js
...
host.ip/tablet/lib

im Log ist mir aber auch nichts aufgefallen und bei der 2.5er funktionierte es auch

[klausw]

In der widget_simplechart.js

muss Zeile 108 von:

Code Auswählen Erweitern

url: ftui.config.fhem_dir,

auf:

Code Auswählen Erweitern

url: ftui.config.fhemDir,

geändert werden. Sonst wird das Verzeichnis, in dem sich die html Datei befindet als FHEM Verzeichnis verwendet.


Könntest du auch bitte bei der Auswertung von fhemweb_url einbauen, das wenn nur "/fhem" oder so drin steht "location.origin" davor gehängt wird?
Da ich lokal mit Ip zugreifen möchte und remote mit dyndns Name kann ich nicht die komplette URL angeben.
Vorschlag ab Zeile 360 fhem-tablet-ui.js:

Code Auswählen Erweitern

ftui.config.fhemDir = $("meta[name='fhemweb_url']").attr("content") || location.origin + "/fhem/";
ftui.config.fhemDir = ftui.config.fhemDir.replace(/^\//, location.origin + '/');
ftui.config.fhemDir = ftui.config.fhemDir.replace('///', '//');

Edit:
Zeile 1620 der widget_chart.js sollte vermutlich auch auf  ftui.config.fhemDir umgestellt werden. Sonst würde mein Vorschlag sicher nicht funktionieren 

Edit2:
folgende Files nutzen auch direkt fhemweb_url aus den Metadaten
js/widget_highchart.js
js/widget_wdtimer.js
js/widget_fullcalview.js
js/widget_weekprofile.js
js/widget_svgplot.js
js/widget_weather.js
js/widget_chart.js
js/widget_readingsgroup.js
js/widget_highchart3d.js

[Brause]

Hallo Klaus

Ich greife lokal auch via IP und von extern via dynDNS zu.
Ich habe den meta "fhemweb_url" überhaupt nicht gesetzt und hatte bisher noch keine Probleme,
FTUI hat immer den richtigen Weg gefunden.

Gruss Peter

[PatrickR]

Hi!

Hi, kann mich nur anschließen...Websock inkl CSRF-Token läuft top. Sowohl vom Tablet (Android 5 mit FullyBrowser), als auch vom Mac mit Firefox&Safari.
VG
Christian

Von der CSRF-Lobpreisung möchte ich mich ausdrücklich distanzieren. Die funktionierte bei mir - im Gegensatz zu websocket - noch nie.

Patrick

[klausw]

Ich greife lokal auch via IP und von extern via dynDNS zu.
Ich habe den meta "fhemweb_url" überhaupt nicht gesetzt und hatte bisher noch keine Probleme,
FTUI hat immer den richtigen Weg gefunden.

Das könnte bei meiner ersten FHEM Instanz funktionieren, da sie unter host/fhem läuft
Aber meine zweite FHEM Instanz läuft z.B. unter host/nocheinfhem
Spätestens dann funktioniert es nicht mehr.

[setstate]

Hi!

Von der CSRF-Lobpreisung möchte ich mich ausdrücklich distanzieren. Die funktionierte bei mir - im Gegensatz zu websocket - noch nie.

Patrick

Ich habe gerade festgestellt, wenn ich über Portweiterleitung auf FHEM zugreife, klappt csrf nicht. Habe also Potential zum Debuggen gefunden ...   

[PatrickR]

Hi!

Ich habe gerade festgestellt, wenn ich über Portweiterleitung auf FHEM zugreife, klappt csrf nicht. Habe also Potential zum Debuggen gefunden ...

Ich habe auch gerade mal geschaut. Das Problem ist möglicherweise irgendein Cross-Origin-Schutz. FHEMWEB antwortet korrekt mit dem Header (mit Dump verifiziert), aber jqXHR.getResponseHeader('X-FHEM-csrfToken'); gibt null zurück, d. h. irgendwo auf Clientseite wird der Wert vernichtet. jqXHR.responseText ist spannenderweise korrekt. CORS habe ich übrigens in der zugehörigen Web-Instanz gesetzt.

Patrick

[PatrickR]

Mahlzeit!

So, Problem gelöst:

Code Auswählen Erweitern


# diff -uNr /root/01_FHEMWEB.pm.org 01_FHEMWEB.pm
--- /root/01_FHEMWEB.pm.org 2017-02-26 13:30:46.000000000 +0100
+++ 01_FHEMWEB.pm 2017-02-28 20:15:01.453108173 +0100
@@ -422,7 +422,8 @@
               "Access-Control-Allow-Methods: GET POST OPTIONS\r\n".
               "Access-Control-Allow-Headers: Origin, Authorization, Accept\r\n".
               "Access-Control-Allow-Credentials: true\r\n".
-              "Access-Control-Max-Age:86400\r\n" : "");
+              "Access-Control-Max-Age:86400\r\n".
+              "Access-Control-Expose-Headers: X-FHEM-csrfToken\r\n": "");
    $FW_headerlines .= "X-FHEM-csrfToken: $defs{$FW_wname}{CSRFTOKEN}\r\n"
         if($defs{$FW_wname}{CSRFTOKEN});

Das überredet den Browser zur Kooperation (wenn CORS gesetzt ist). Praktischerweise musst Du an TabletUI nichts ändern.

/Edit: Gerade gemerkt, dass das Problem schonmal unabhängig von TabletUI andiskutiert wurde: https://forum.fhem.de/index.php/topic,67848.0.html

Patrick

[setstate]

Mahlzeit!

So, Problem gelöst:

Code Auswählen Erweitern


# diff -uNr /root/01_FHEMWEB.pm.org 01_FHEMWEB.pm
--- /root/01_FHEMWEB.pm.org 2017-02-26 13:30:46.000000000 +0100
+++ 01_FHEMWEB.pm 2017-02-28 20:15:01.453108173 +0100
@@ -422,7 +422,8 @@
               "Access-Control-Allow-Methods: GET POST OPTIONS\r\n".
               "Access-Control-Allow-Headers: Origin, Authorization, Accept\r\n".
               "Access-Control-Allow-Credentials: true\r\n".
-              "Access-Control-Max-Age:86400\r\n" : "");
+              "Access-Control-Max-Age:86400\r\n".
+              "Access-Control-Expose-Headers: X-FHEM-csrfToken\r\n": "");
    $FW_headerlines .= "X-FHEM-csrfToken: $defs{$FW_wname}{CSRFTOKEN}\r\n"
         if($defs{$FW_wname}{CSRFTOKEN});

Das überredet den Browser zur Kooperation (wenn CORS gesetzt ist). Praktischerweise musst Du an TabletUI nichts ändern.

/Edit: Gerade gemerkt, dass das Problem schonmal unabhängig von TabletUI andiskutiert wurde: https://forum.fhem.de/index.php/topic,67848.0.html

Patrick

Das ging aber flott.
Ich habe parallel ein Workaround auf Clientseite eingebaut.
Die zurück gelieferte Seite enthält auch den csrf.

Code Auswählen Erweitern

ftui.getPart(data, ".*fwcsrf='(.*?)'.*");

Siehst du eine Cache, dass das übernommen wird? Solange lasse ich den Workaround drin.