Vorbereitung auf FHEM 5.8 Release

[rudolfkoenig]

Da der Forumsumzug (hoffentlich) erledigt ist, wuerde ich gerne in etwa 2 Wochen ein FHEM 5.8 Paket fertigmachen, damit nicht der Eindruck entsteht, bei FHEM passiert seit 2 Jahren nichts.

Deswegen bitte ich die Entwickler riskante Umbauten lieber aufzuschieben. Weiterhin waere es mir wichtig die mit Featurelevel 5.8 eingefuehrten Aenderungen breiter zu testen, indem man jetzt schon "attr global featurelevel 5.8" setzt. Das waeren die ab sofort per Voreinstellung aktiven Attribute:
- perlSyntaxCheck
- csrfToken

[Dr. Boris Neubert]

by setting the global attribute perlSyntaxCheck, a syntax check will be executed upon definition or modification, if the command is perl and FHEM is already started.

Was bedeutet in diesem Zusammenhang "FHEM is already started"? Heißt das, dass der Syntaxcheck nicht für Perl-Code in der Konfigurationsdatei ausgeführt wird?

[rudolfkoenig]

Genau das heisst es.

Beim Starten faende ich die viele Meldungen verstoerend, beim Erzeugen (z.Bsp. im DEF Fenster) dagegen eher hilfreich.
Fuer "Oldtimer" waere vielleicht eine explizite Schleife sinnvoll, ob/wie/wann das kommt, sehen wir nachdem die aktuelle Version reibungslos laeuft.

[Dr. Boris Neubert]

Beim Starten faende ich die viele Meldungen verstoerend, beim Erzeugen (z.Bsp. im DEF Fenster) dagegen eher hilfreich.

Ich kann mir noch nicht so recht etwas darunter vorstellen, wie die Meldungen aussehen, und warum bei korrektem Perl-Code in der Konfigurationsdatei überhaupt Meldungen kommen.

Ins Blaue hinein: könnte attr global perlSyntaxCheck nicht noch ein optionales Argument onStartup, onCreate, always erhalten, mit dem das gesteuert wird?

[rudolfkoenig]

Ich kann mir noch nicht so recht etwas darunter vorstellen, wie die Meldungen aussehen, und warum bei korrektem Perl-Code in der Konfigurationsdatei überhaupt Meldungen kommen.

Na beim korrekten Perl code muss man die auch nicht checken, und damit Zeit vergeuden. Ich sage nur 400 notifys auf einem RPi. Es gibt bestimmt auch viele Leute, die "Muell" rumliegen haben. Die will ich nicht automatisch nerven.

Wir koennen gerne Optionen einfuegen, ich haette aber gerne erstmal Feedback zum aktuellen Version.

[betateilchen]

es sei auch noch an diesen Thread erinnert, in dem man mal schauen könnte, ob alle wichtigen Informationen drinstehen.

Vermutlich werden nach dem Release wieder viele gleichartige Fragen auftauchen, dann könnte man direkt auf den Sammelthread mit den Änderungen hinweisen.

[justme1968]

antwort für hier: https://forum.fhem.de/index.php/topic,53847.msg578480.html#msg578480. vielleicht kann jemand die drei beiträge aus dem anderen thread hier her schieben?

du hast recht. ich habe mehrere parallele verbindungen nicht richtig auseinandergehalten. es betrifft nicht die longpoll verbindung an sich sondern nur die cmd verbindungen.

um das token von fhemweb an den client zu übertragen wird es aktuell als fwcsrf= parameter im body tag angehängt. die longpoll verbindung hat aber keinen body. wenn man es in die daten steckt muss man irgendetwas kompatibles einbauen. statt fwcsrf= im body zu verwenden könnte man das token auch einfach in den http header stecken. etwa so:

Code Auswählen Erweitern

--- 01_FHEMWEB.pm (revision 13344)
+++ 01_FHEMWEB.pm (working copy)
@@ -413,6 +413,8 @@
               "Access-Control-Allow-Credentials: true\r\n".
               "Access-Control-Max-Age:86400\r\n" : "");

+  $FW_headerlines .= "X-FHEM-csrfToken: $defs{$FW_wname}{CSRFTOKEN}\r\n" if( $defs{$FW_wname}{CSRFTOKEN} );
+
   #########################
   # Return 200 for OPTIONS or 405 for unsupported method
   my ($method, $arg, $httpvers) = split(" ", $FW_httpheader[0], 3);

dann wäre es auch im http header enthalten mit der die longpoll anfrage beantwortet wird.

ich habe hier eine version von alexa-fhem die damit prinzipiell funktioniert. unschön ist das ich erst mal warten muss bis die longpoll verbindung aufgebaut ist und ich das token habe bevor es weiter geht. da longpoll, die abfrage der geräte liste per jsonlist2, das prüfen und setzen von ein paar attributen aber eigentlich asynchron passieren ist das warten sehr unschön.


wegen der alternativen anmelde methode: das problem ist nicht die anmeldemaske sondern all die anwendungen die nicht interaktiv sind und eine solche maske nicht verwendet können. soll heissen wichtig ist wie die anmelde information zu fhem gelangt, wie ein token zurück kommt und wie dieses dann in den folgenden anfragen verwendet werden kann. klingt eigentlich nach oauth

aber zurück zum csrf token: wenn du tatsächlich in zwei wochen ein release fertig machen willst würde ich das token für 5.8 wieder abschalten. jedes frontend ausser fhemweb hat sonst erst mal ein problem.

[rudolfkoenig]

ist das warten sehr unschön.

Soll ich dein Patch einbauen, oder bleiben wir bei unschoen?
Ich bin fuer Alternativen auch zu haben...

[fhainz]

vielleicht kann jemand die drei beiträge aus dem anderen thread hier her schieben?

ich wollte das eben machen, aber ich glaub ich habe irgendwas falsch gemacht. ich lass die finder davon 

[justme1968]

nicht der patch ist unschön sondern der umgang mit dem token wenn man nicht browser ist

wenn das token aktiv ist würde ich es in den header stecken.

aber ich würde es deaktivieren. sonst gehen auf einen schlag ein paar tausend systeme nicht mehr.

[rudolfkoenig]

wenn das token aktiv ist würde ich es in den header stecken.

Du meinst zusaetzlich? Ist das ein "ja, installiere endlich mein Patch"?

aber ich würde es deaktivieren. sonst gehen auf einen schlag ein paar tausend systeme nicht mehr.

Heisst das, dass du gegen die default-Aktivierung von csrfToken bist? Ich will es aber gerne haben, sonst gibt es Aufschrei, wenn einer auf seinem Blog 10 Bilder mit src="http://192.168.178.1+N:8083/fhem?cmd=set .* off" (N=0..9) einbaut, und sein Blog hier verlinkt.

[justme1968]

das war ein: es wäre schön wenn du den patch einchecken würdest.

man könnte auch noch fhemweb umbauen das es einfalls den header nimmer und es dann aus dem body komplett weg lassen.

ich kann nur noch nicht klar genug denken um einen vorschlag zu machen.

sonst gibt es Aufschrei

so gibt es einen aufschrei weil auf einen schlag keine ftui installation mehr geht. ebenso alexa, homekit und ich weiss nicht was noch alles.

ich habe leider auch keine bessere idee...

[Dr. Boris Neubert]

Heisst das, dass du gegen die default-Aktivierung von csrfToken bist? Ich will es aber gerne haben, sonst gibt es Aufschrei, wenn einer auf seinem Blog 10 Bilder mit src="http://192.168.178.1+N:8083/fhem?cmd=set .* off" (N=0..9) einbaut, und sein Blog hier verlinkt.

Offtopic: endlich! Der allgemein verständliche Exploit für das Problem, weswegen ich verlinkte Bilder im Forum verboten habe.

[betateilchen]

Offtopic: endlich! Der allgemein verständliche Exploit für das Problem, weswegen ich verlinkte Bilder im Forum verboten habe.

Nö.

[rudolfkoenig]

@justme1968: eingecheckt. Wg entfernen der csrf aus body: In Chrome kriege ich ein readyState 2 (header received) erst, wenn Daten ueber den Kanal gesendet wurden. Weiterhin kann man mW bei Websocket nicht auf die HTTP Header zugreifen. -> csrf blebt ersetmal im body.

@betateilchen: oller Noergler Was denn nö: leuchtet es Dir nicht ein, oder darf es anderen nicht einleuchten?