Instabilitäten nach Update auf 5.8

[hartenthaler]

Ich habe drei FHEM-Installationen auf raspi 2/3 am laufen. Habe inzwischen alle auf 5.8 aktualisiert. Wegen Problemen mit dem Sicherheitsfeature CSRF habe ich im WEB-Device diese Funktion wieder deaktiviert. Ich habe das Attribut auf 0 gesetzt (oder müsste ich es auf none setzen?).

Dennoch habe ich solche Fehlermeldungen in meinem Logfile:

Code Auswählen Erweitern

2017.02.28 16:21:05 3: FHEMWEB WEB CSRF error: fhem_118945814175341 ne fhem_1.00902499283452e+15. For detals see the csrfToken FHEMWEB attribute
Abgesehn vom Grundsatz, dass bei deaktiviertem CSRF so etwas nicht kommen sollte, scheint mir auch die Fehlermeldung an sich korrupt zu sein:

• bei fhem_1.00902499283452e+15 scheint mir eine lange Ziffernfolge als Exponentialzahl interpretiert zu werden
• "detals" sollte wohl "details" heißen

Es ist auf einem anderen Raspi inzwischen mindestens zwei Mal vorgekommen, dass das gesetzte Attribut csrfToken aus der fhem.cfg verschwunden ist. Hängt eventuell mit einem Systemabsturz zusammen.

Auf allen drei Raspis verwende ich BasicAuth. Bislang wurde ich höchstens beim Neustart meines Chrome-Browsers aufgefordert Userid-Passwort einzugeben. Nun passiert das aber auf allen drei Rechnern recht häufig einfach so zwischendurch. Ich bearbeite etwa im Editor eine xyz.cfg und irgendwann popt dann scheinbar anlaßlos das Fenster mit Userid/Passwort auf. Es geht ohne Probleme nach dem Bestätigen des Fensters weiter. Manchmal passiert es aber dann beim SAVE, dass das Fenster anscheinend hängen bleibt, d.h. der Editor-Inhalt ist weiter sichtbar, es kommt keine Bestätigung, dass gesichert worden ist (allerdings wurde bislang der Inhalt tatsächlich aber korrekt gesichert).

Ab und zu bleibt ein FHEM-Fenster komplett weiß. Dann hilft es manchmal einfach im Browserverlauf eine frühere Seite erneut aufzurufen, manchmal hilft ein Refresh der Web-Seite (dann mit der Aufforderung Userid/passwort einzugeben), manchmal bleibt aber auch nur übrig über die Konsole FHEM zu stoppen und neu zu starten. Irgendwie nicht mehr so rund wie früher.

Auf meinem ältesten Raspi habe ich das Problem: bei der Eingabe in der FHEM-Kommandozeile von "shutdown restart" öffnet sich ein pop-up-Fenster mit einer javascript-Fehlermeldung und der Befehl wird nicht ausgeführt. Dann hilft es, wenn ich irgendeinen FHEM-Menüpunkt anklicke und nach dem Laden der neuen Seite den Befehl erneut in der Kommandozeile eingebe.

Bin ich der einzige mit solchen Problemen seit 5.8?

[rudolfkoenig]

- FHEM 5.8 hat nur eine Voreinstellung aktiviert, die jeder seit ueber einem Jahr haette aktivieren koennen. Mit "attr global featurelevel 5.7" stellt man die alten Voreinstellung ein.
- wenn csrfToken entfernt wird (wie auch immer), dann gilt das default-Verhalten: es wird eine zufaellige generiert, beim Zugriff mit "falschen" erscheint im Log eine Meldung und die Seite bleibt leer.
- ob Exponentialzahl oder nicht, ist egal, Hauptsache eindeutig bzw. beim Vergleich gleich.

Es hilft mir nicht, wenn ich ein Haufen wage Beschreibungen bekomme, die vermutlich Mehrfach-Folgefehler sind: dazu kann ich nur "Tut mir leid" sagen. Wenn ich helfen soll, dann brauche ich genaue / nachvollziehbare  Beschreibungen, und ein Problem auf einmal.

[hartenthaler]

Gut, ist mir schon klar, dass das ggf. miteinander verwobene komplexe Dinge sein können. Also der Reihe nach, nun zum ersten Problem, das sich nach einer systematischen Analyse schon deutlich geklärt hat:

Das Attribut csrfToken hatte bei mir den Wert 0, da ich irrtümlich angenommen habe, dass das mit "none" identisch sei; das Internal CSRFTOKEN hat den Wert fhem_6540530392589.26 (was mich leicht irritierte); ich nutze den Chrome-Browser; habe für WEB BasicAuth konfiguriert und bin angemeldet.

Ich bearbeite im eingebauten Editor ("Edit files") eine xyz.cfg (ja, soll man eigentlich nicht tun), alles funktioniert. Ich drücke auf den SAVE-Button und in dem Moment erscheint das Pop-Up-Fenster mit der Abfrage von UserId-Passwort (erschien früher nie). Warum kommt hier die Abfrage?

Wenn ich mir den Source-Code dieser Web-Seite ansehe, dann erscheint dort an verschiedenen Stellen fwcsrf-Parameter.

Code Auswählen Erweitern


<div id="hdr">
<table border="0" class="header"><tr><td style="padding:0">
<form method="post" action="/fhem">
<input type="hidden" name="fw_id" value="2471"/>
<input type="hidden" name="fwcsrf" value="fhem_6540530392589.26"/>
<input type="text" name="cmd" class="maininput" size="40" value=""/>
</form>
</td></tr></table>
</div>
<div id='content' >
<form method="post">
<input type="submit" name="save" value="Save system_datennetz.cfg" />
&nbsp;&nbsp;
<input type="submit" name="saveAs" value="Save as" />
<input type="text" name="saveName" class="saveName" size="30" value="system_datennetz.cfg"/>
<br><br>
<input type="hidden" name="cmd" value="style save system_datennetz.cfg "/>
<input type="hidden" name="fwcsrf" value="fhem_6540530392589.26"/>
<textarea  name="data" cols="80" rows="30">


Damit war mir klar, dass der Wert 0 für das Attribut csrfToken weder bedeutet, dass die Funktion deaktiviert ist, noch dass das Token damit auf den Wert "0" gesetzt wird. Ist 0 der interne Wert für "random"? Dann sollte man in der commandref den möglichen Wertebereich vielleicht noch konkreter formulieren:
===
Falls auf numerische Werte größer Null gesetzt, wird der Wert des Attributes als fwcsrf Parameter bei jedem über FHEMWEB abgesetzten Kommando verlangt, es dient zum Schutz von Cross Site Resource Forgery Angriffen. Falls der Wert random oder 0 ist, dann wird ein Zufallswert beim jeden FHEMWEB Start neu generiert, falls er none ist, dann wird kein Parameter verlangt. Die Vergabe eines festen Wertes wird aus Sicherheitsgründen nicht empfohlen. Default ist random für featurelevel 5.8 und größer, und none für featurelevel kleiner 5.8
===
Ansonsten bleibt die Frage warum das Passwort ab und zu abgefragt wird, wenn der CSRF-Schutz aktiv ist.

[rudolfkoenig]

Ich habe ein paar kleine Korrekturen vorgenommen, und statt doku zu Aendern csrfToken 0 zugelassen, siehe auch https://forum.fhem.de/index.php/topic,67372.msg596630.html#msg596630.

Die Passwortabfrage kommt, weil bei falschen csrf FHEM neuerdings "401 Unauthorized" zurueckliefert, und daraufhin der Browser das gespeicherte basicAuth vergisst (das war mir nicht bewusst). Nach einem rereadcfg wurde das Token neu gesetzt. Das habe ich fuer "leeres" csrfToken Attribut vor paar Tagen, fuer "random" jetzt gefixt, ich kann jetzt fhem.cfg uebers Frontend mit csrfToken und basicAuth editieren.

[hartenthaler]

Danke Rudolf! Diese Ecke hat sich somit stabilisiert.

Nun zum nächsten Problem:

Code Auswählen Erweitern


fhemweb.js line 211:
Uncaught TypeError: Cannot read property 'top' of undefined


Dieses Fehlermeldungsfenster erschien gerade, als ich auf den Link "Device specific help" rechts unten auf einer Device-Ansicht-Seite geklickt habe. Und der Hilfetext wurde nicht angezeigt. Ein erneutes Klicken auf diesen Link - und schon funktioniert es wieder. Der js-Fehler tritt sehr selten auf, aber ich hatte ihn zuvor schon mal seit 5.8. Davor habe ich so ein Fenster noch nie gesehen. An csrf sollte es nicht liegen (ist auf none gesetzt).

[rudolfkoenig]

fhemweb.js line 211:

Dieses Problem hat nichts mit 5.8 zu tun, diese Stelle hat sich seit 2015-08-09 nicht veraendert.
Es passiert, wenn man auf dem Link noch einmal klickt, bevor FHEMWEB die Hilfeseite ausgeliefert hat.
Wenn FHEM klemmt, dann ist das relativ einfach zu reproduzieren.
Habe eine Pruefung eingebaut, die Meldung sollte nicht mehr kommen, die Hilfe wird allerdings verworfen.