Release Notes für das nächste Major Release

[betateilchen]

Wann auch immer das nächste Major Release geplant ist, ich fange hier einfach mal eine Sammlung wichtiger Änderungen an, die man zu gegebener Zeit in eine Ankündigung zum nächsten Releasewechsel aufnehmen sollte.

• Modul 55_GDS.pm von ./FHEM nach ./contrib/GDS/ verschoben
• Modul 55_weco.pm von ./FHEM nach ./contrib verschoben
• configDB: "configdb dump" vereinfacht die Datensicherung

Vielleicht wird dieser Thread vom einen oder anderen Entwickler einfach als Gedächtnisstütze genutzt.

[CoolTux]

• Einführung  ReadingsAge
• RegEx Syntax ala watchdog und notify

[justme1968]

neue features und eventuell nicht rückwärts kompatible änderungen für anwender:

• userReadings trigger automatisch mit implizitem $ am ende
• timestamp-on-change-reading attribut
• deviceOverview attribut
• perlSyntaxCheck attribut
• multiline attribute
• TIMED_OnOff internal

für entwickler:

• parseParams, $hash->{parseParams}
• SetExtensionsCancel, $hash->{TIMED_OnOff}
• deviceEvents state handling
• AsyncOutputFn, asyncOutput/$hash->{CL}
• perlSyntaxCheck

[rudolfkoenig]

- FHEMWEB: ab featurelevel 5.8 ist "csrfToken random" die Voreinstellung. Um es abzuschalten bitte  "csrfToken none" setzen.

@justme1968: wo findet man die multiline Attribute? Bitte etwas mehr "idiotensicher" formulieren.

[justme1968]

das sollte bedeuten: attribute können jetzt mehrzeilig sein, es wird dazu zwischen fhemweb und fhem umgewandelt und auch bei textfield-long berücksichtigt.

[betateilchen]

Bitte etwas mehr "idiotensicher" formulieren.

es wird dazu zwischen fhemweb und fhem umgewandelt und auch bei textfield-long berücksichtigt.

Vermutlich bin ich nicht Idiot genug, um sowas zu verstehen, und da geht es mir vermutlich wie vielen anderen Anwendern auch. Lass solche technischen Formulierungen in release notes bitte einfach weg, das führt mehr zu Verwirrung als dass es jemandem nützt.

[justme1968]

- der thread hier ist eine gedankenstützt für die releasenotes, nicht der text der in den release notes landen soll

- 'attribute können jetzt mehrzeilig sein ist' ist weder technisch noch für anwender unverständlich 

- die genauere erklärung war für rudi als erinnerung, nicht der text der in den release notes landen soll

- wenn ich rudi einen frage beantworte dann hat auch das erst mal nichts mit anwendern zu tun

- 'ein mach es so einfach wie möglich, die verstehen das sowieso nicht' würde ich mir als anwender von dir und von jedem anderen verbitten

@rudi: die multline attribute unter anderem bei stateFormat, comment, diversen readingsGroup attributen, sysstat und noch anderen stellen mehr.

[betateilchen]

Du bringst mal wieder ein paar Dinge völlig durcheinander und führst in Deiner Liste Punkte auf, die überhaupt nicht zur Diskussion standen.

Lassen wir das einfach. Es hätte mich auch sehr gewundert, wenn Du nicht auch diesen Thread ad absurdum führen würdest.

Schade eigentlich.

[rudolfkoenig]

Jungs, contenance, so heiss ist doch gar nicht.
Ich habe nun verstanden, worum es geht.

[Dr. Boris Neubert]

Nur die ggf. die Abwärtskompatibilität brechenden Änderungen seit 5.7:

66_ECMD, 67_ECMDDevice:
              - if split is used, the strings at which the messages are split
                are still part of the messages
              - no default attributes for requestSeparator and responseSeparato
              - input of raw data as perl-encoded string (for setting
                attributes)
57_Calendar: complete rewrite
             see http://forum.fhem.de/index.php/topic,48315.0.html

[justme1968]

ich bin gerade auf ein problem mit dem csrfToken token und der default aktivierung bei featurelevel 5.8 aufmerksam gemacht worden.

es betrifft homebridge-fhem, alexa-fhem. vermutlich aber auch tabletui, jedes andere alternative frontend und natürlich jeden anderen beabsichtigte steuerung von fhem per url.

das problem ist das hier in keinem fall eine 'normale' fhemweb seite aufgerufen wird über den man das csrf token regulär bekommen würde. das abfragen des tokens aus den internals wäre ziemlich unsauber. die konfiguration des tokens geht nicht weil zufällig. ein festes token könne man konfigurieren, der zusätzliche schritt wird aber viele überfordern.

eine mögliche lösung wäre wenn das token beim aufbau einer longpoll verbindung mit geschickt wird.

oder hat jemand eine bessere idee?

[rudolfkoenig]

Habe prinzipiell nichts gegen dem Vorschlag, muss nur irgendwie kompatibel sein.

[justme1968]

hab noch ein bisschen geforscht... das problem fängt leider schon früher an. der aufbau der longpoll verbindung wird ohne token schon abgelehnt.

also neuer vorschlag:
- longpoll verbindung auch ohne token erlauben

- das token nicht in den body stecken sondern in den header. dann gibt es keine probleme mit kompatibilität da die eigentlichen daten unverändert bleiben.

[rudolfkoenig]

der aufbau der longpoll verbindung wird ohne token schon abgelehnt.

Das sollte nicht der Fall sein. Es wird nur abgelehnt, wenn cmd im URL oder data gesetzt ist.

- longpoll verbindung auch ohne token erlauben

Wird bereits gemacht. Solange wir keine Befehle ueber longpoll ausfuehren, ist das mAn auch kein Bug.

- das token nicht in den body stecken sondern in den header. dann gibt es keine probleme mit kompatibilität da die eigentlichen daten unverändert bleiben.

Das habe ich nicht verstanden.

Nachdem ich gerade ueber csrf nachgedacht habe: da basicAuth parallel zu Seiten, die CORS erlauben und gehackt wurden, nicht sicher ist (csrfToken hin oder her), muessten wir irgendwann eine alternative Anmeldemethode etablieren, mit selbst-mitgebrachte Anmeldemaske und so.

[betateilchen]

Wäre dieser Thread https://forum.fhem.de/index.php/topic,66484.0.html

nicht der bessere Ort, um über solche Probleme/Änderungen noch vor dem Major Release zu diskutieren?