Nutzung des csrfToken - Anleitung?

Begonnen von ManuZz, 28 Februar 2017, 10:03:17

Vorheriges Thema - Nächstes Thema

Benni

#60
Ich hab's eben auch schnell getestet, allerdings nur mit einem selbst definierten FHEMWEB-Device, nicht mit dem Standard-Device und dort hat es funktioniert, wie erwartet.

Allerdings hatte ich dabei auch das von Otto schon mal beschriebene Problem, dass ich beim setzen mittels Attribut-"Assistent" in der FHEMWEB-Device-Detailansicht (also nicht über die FHEMWEB-Kommandozeile) *zack* auf einer leeren (weißen) Seite gleandet bin und das Attribut nicht gesetzt wurde.

Letztes Update war vor 2 Stunden ;)

Update: Bei mir funktioniert es auch mit dem Standard-FHEMWEB-Device WEB auf 8083!
@Otto: Save vergessen?

Benni

#61
@Rudi: Kann man das Neu-Erzeugen des csrfToken auch zur Laufzeit irgendwie anstoßen, ohne FHEM neu zu starten?

Edit: Wenn ich das Attribut lösche passierte erst mal nichts, bzw. wird das CSRF-Token sogar erst mal komplett gelöscht. Wenn ich es dann explizit auf random setze, wird wieder eines generiert.

rudolfkoenig

@Otto:
Zitat01_FHEMWEB.pm     13585 2017-03-03 08:26:40Z rudolfkoenig
Ist nicht aktuell.
ZitatUnd das Verhalten tritt nicht bei einem selbst definiertem WEB auf, sondern nur beim Standard WEB 8083!
Bitte sei hier genau. Ich habe gestern einen Bug gefixt, der bei nicht gesetzten csrfToken das nur fuer die FHEMWEB Instanz mit dem Namen WEB gesetzt hat.

@Benni:
Bin verwirrt. Tut es jetzt oder nicht? Ich habe kein Problem csrfToken in der FHEMWEB Detail Ansicht in der attr Zeile zu setzen.

ZitatKann man das Neu-Erzeugen des csrfToken auch zur Laufzeit irgendwie anstoßen, ohne FHEM neu zu starten?
Wenn man es auf "random" setzt, dann wird ein neuer Token generiert. Danach funktioniert zwar einiges immer noch (alle Links ohne cmd und alle set/get/attr Knoepfe, da sie im Fehlerfall csrfToken neu holen), aber die Links mit cmd drin (Edit files, Select style, Event monitor) nicht, deswegen empfehle ich nach sowas ein Reload der Seite im Browser. Duerfte selten vorkommen, will es deswegen nicht programmatisch behandeln.

Benni

Rudi,

bei mir funktioniert es mit allen FHEMWEB-Instanzen, so wie erwartet und wie von dir Dokumentiert.

Otto123

Hallo Rudi,

ich dachte update von gestern ist aktuell und Du machst am WE frei  ;D
Alles gut mit der Version ->  01_FHEMWEB.pm     13599 2017-03-04 13:38:24Z rudolfkoenig funktioniert alles wie dokumentiert  :)

@Benni ich bin sehr froh das Du den Effekt auch hattest. Ich habe gestern gedacht mein Pumuckel  treibt arg Schabernack mit  mir. Ich hatte so viel unterschiedliche Effekte, irgendwann ist man nicht mehr sicher ob man nicht doch halluziniert.  :D

Ich hatte wie gesagt gestern früh update gemacht und dachte damit ist alles gut. Ja, und save hatte ich durchaus auch schon mal vergessen aber nicht heute früh. Nur update hatte ich heute früh "vergessen".  :-X

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Otto123

Mir ist noch folgendes Verhalten aufgefallen, das soll aber weder Kritik oder Feature Request sein.

Man kann sich eigentlich (mit einer Ausnahme) auf das csrfToken verlassen was man nach einem Refresh in der Detailansicht des WEBs sieht.

Ausgangszustand:
attr nicht gesetzt - nach neustart FHEM -> zufälliges Token steht in den Internals und wird auch verwendet
attr auf <Wert> gesetzt -> das Token mit dem festen Wert wird sofort  in den Internals angezeigt und auch verwendet
attr auf none gesetzt -> attr wird angezeigt, die Anzeige der Internals ändert sich nicht (Token steht noch drin) es wird aber kein csrfToken verwendet
attr gelöscht -> es wird kein attr und kein Internal angezeigt (auch nach Browser Refresh nicht) und kein csrfToken verwendet
attr auf random gesetzt -> es wird das Token sofort in den Internals angezeigt und sofort verwendet.

Aus meiner Sicht zwei ganz leicht inkonsistente Zustände:
Wenn man nach Versuchen den "Original Zustand" wieder herstellt und das Attribute löscht wird das zufällige Token erst nach einem shutdown restart wieder verwendet.
Setzt man auf none wird kein Anzeigerefresh in den Internals durchgeführt.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Benni

#66
Otto,

ich kann den Pumuckl sogar reproduzieren  ;D

Wenn ich von meiner Standard-FHEMWEB-Instanz (WEB auf 8083) aus das csrfToken einer anderen FHEMWEB-Instanz mittels "attr"-Button im Device-Detail der anderen FHEMWEB-Instanz (WEBTEXT)  auf einen festen Wert (bspw. benni_1234567) setzen will, dann tritt der Wusch-Effekt der weißen, leeren Seite auf, also Ottos s.g. "Pumuckel" ;).
Das ist bei mir zuverlässig reproduzierbar.

Wenn ich dazu den Console-Log im Browser (btw. ich verwende Chrome) offen habe erhalte ich dabei folgende Ausgabe (s. Screenshot im Anhang)

Gleichzeitig erhalte ich im FHEM-Log folgenden Eintrag:


2017.03.05 18:49:01 3: FHEMWEB WEB CSRF error:  ne csrf_295575378963423. For detals see the csrfToken FHEMWEB attribute


Der darin genannte Token ist der korrekte Token meiner Standard FHEMWEB-Instanz:


Internals:
   CFGFN
   CONNECTS   210
   CSRFTOKEN  csrf_295575378963423
   DEF        8083 global
   FD         5
   NAME       WEB
   NR         3
   NTFY_ORDER 50-WEB
   PORT       8083
   STATE      Initialized
   TYPE       FHEMWEB


Da läuft wohl irgendwas mit den Tokens ziwschen den FHEMWEB-Instanzen schief.


Otto123

#67
Benni! exakt so ist es!

Aber:

nur wenn in der anderen Webinstanz nach einem Neustart noch kein attr csrfToken gesetzt war. Ich bekomme den Fehler
2017.03.05 19:04:54 3: FHEMWEB WEB CSRF error: csrf_21502981895379 ne csrf_214810837363824. For detals see the csrfToken FHEMWEB attribute

Mein WEB 8083 lief auf zufälligen csrfToken und mein WEBfest 8089 zu diesem Zeitpunkt auch.

Wenn man es einmal gesetzt hatte, dann tritt der Effekt nie wieder auf. Bis man das attr löscht, save macht  ;), neu startet und wieder versucht vom WEB 1 aus im WEB 2 das attr NEU zu setzen.


Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Benni

Zitat von: Otto123 am 05 März 2017, 19:08:38
nur wenn in der anderen Webinstanz nach einem Neustart noch kein attr csrfToken gesetzt war.

Es scheint bei mir keine Rolle zu Spielen, wie das beim Systemstart gesetzt ist.

rudolfkoenig

ZitatWenn man nach Versuchen den "Original Zustand" wieder herstellt und das Attribute löscht wird das zufällige Token erst nach einem shutdown restart wieder verwendet.
Das habe ich gerade gefixt.

ZitatSetzt man auf none wird kein Anzeigerefresh in den Internals durchgeführt.
Das hat mit der Unvollkommenheit der fhemweb XHR Handling zu tun: fhemweb.js laedt die Seite nicht neu, wenn er meint, das gerade Geaenderte wird per longpoll eh gemeldet. Aenderungen an Internals werden aber nicht gemeldet.

Wenn ich wg. dem "Pumuckl" was machen soll, dann meldet euch nochmal mit einer Beschreibung, was ich auch verstehe :)

Benni

@Rudi:

Zur Reproduktion brauchst 2 FHEMWEB-Instanzen:


  • "WEB" auf Port 8083 mit csrfToken auf Random (Attribut csrf-Token nicht gesetzt bei Featurelevel 5.8 )
  • "WEBTEXT" auf beliebigem Port (bei mir auf 8093), ebenfalls ohne gesetztes Attribut csrfToken

Du öffnest im Browser die FHEMWEB-Instanz "WEB" auf Port 8083 und öffnest darin die Detail-Ansicht des FHEMWEB-Device "WEBTEXT"

Du stellst das Attribut csrfToken auf einen fixen Wert ein, aber nicht per FHEMWEB-Kommandozeile, sondern über den Attribut-"Assistenten" (s. Screenshot)

Beim Klick auf den "attr"-Button passiert's dann.

Reicht das als Beschreibung?



rudolfkoenig

ZitatReicht das als Beschreibung?
Ja. Das Problem hat nichts mit csrfToken zu tun gehabt, man hat es wohl nur deswegen gemerkt.
Der Bug ist stolze 4.5 Jahre alt. Habs gefixt & eingecheckt.

Benni

Zitat von: rudolfkoenig am 05 März 2017, 23:25:12
Der Bug ist stolze 4.5 Jahre alt.

Dann kennen wir ja nun auch Pumuckls Alter ;D

Otto123

Guten Morgen,

dann ist der Bug ja älter als Rudis Account hier im Forum. Somit wurde an historischen "Originaldokumenten" gefixt?
Wann hat FHEM eigentlich Geburtstag?

;D

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rudolfkoenig