FHEMWEB WEB CSRF error

Begonnen von HCS, 18 Februar 2017, 20:45:44

Vorheriges Thema - Nächstes Thema

HCS

Ich habe (nur auf einem meiner Test-Systeme) den Effekt, dass z.B. ein
192.168.31.18:8083/fhem?cmd=reload 36_LaCrosseGateway.pm&detail=LGW212
mit einer leeren html-Seite endet und dieser Log-Eintrag entsteht:
FHEMWEB WEB CSRF error:  ne fhem_68465911005880.9

Hat jemand einen Tip, woran das liegen könnte oder wo ich mit dem Forschen ansetzen sollte?

rudolfkoenig

Ab featurelevel 5.8 ist csrfToken in FHEMWEB per Voreinstellung aktiv.

Damit weigert sich FHEMWEB Befehle auszufuehren, wenn das fwcsrf Parameter nicht das richtige Token enthaelt.
Man kann es mit "none" abstellen, siehe auch commandref. Das Token wird im HTTP-Header und im body als Attribut ausgeliefert, wenn die Seite von FHEMWEB generiert wird.

HCS

Danke. So geht es.
Jetzt fange ich auch langsam an, die Diskussion im "Vorbereitung auf FHEM 5.8 Release" thread wirklich zu verstehen :)

betateilchen

Zitat von: HCS am 18 Februar 2017, 21:46:10
Danke. So geht es.

Wie geht es? Hast Du das token mit "none" abgeschaltet oder hast Du einen Link generiert, der einen Befehl ausführt?
Ich stehe nämlich grade vor dem Problem, dass in meinen InfoPanels die Buttons nicht mehr funktionieren.

http://fhem-rpi3:8083/fhem?XHR=1&cmd=set%20az_Verteiler%20toggle
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

csrfToken habe ich vor 18 Monaten eingebaut, man haette es nur aktivieren muessen. Selbst nach meiner "Drohung" hat es kaum einer gemacht, und jetzt funktionieren so "exotische" Dinger wie Tablet-UI, Dashboard und InfoPanel nicht. Wehe, wenn jemand wieder mit der Idee von Developer und Stable-Release kommt.

betateilchen

Du hast vor 18 Monaten was eingebaut, was ausser Dir wenige Entwickler überhaupt verstanden haben.

Und ich habe mich ja nicht beschwert - ich bin ja bereit, mein InfoPanel entsprechend anzupassen. Aber dabei hilft mir Dein letzter Beitrag nicht wirklich weiter. Gestern habe ich bereits eine Änderung eingebaut, um den automatischen refresh in InfoPanel wieder zum Laufen zu bringen. Das habe ich wenigstens noch verstanden

Aber wie muss jetzt so ein Link aussehen, um ein cmd= auszuführen?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

HCS

Zitat von: betateilchen am 20 Februar 2017, 20:27:40
Wie geht es? Hast Du das token mit "none" abgeschaltet oder hast Du einen Link generiert, der einen Befehl ausführt?
Habe es schlicht und schmerzfrei mit none abgeschaltet. Dann muss ich mein ganzen "Entwickler-Helferlein-Links" nicht ändern.

Wenn ich das nicht völlig falsch verstehe, ist es ein Sicherheitsfeature, das man braucht oder (wie ich) nicht und dann halt abschaltet.

rudolfkoenig

ZitatAber wie muss jetzt so ein Link aussehen, um ein cmd= auszuführen?

http://fhem-rpi3:8083/fhem?XHR=1&cmd=set%20az_Verteiler%20toggle&fwcsrf=<csrfToken>

betateilchen

Danke. Hatte ich vorhin schon erfolglos so probiert, aber jetzt klappt das.

button 13 0 0 158 78 5 5 {"http://fhem-rpi3:8083/fhem?XHR=1&amp;cmd=set%20az_Drucker%20toggle".$FW_CSRF} {"Drucker"}
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Schlimbo

Hallo zusammen,
Ich hatte auch das Problem, dass meine Steuerung über die Android App Tasker nicht mehr funktioniert hatte.
Nach ein wenig Recherche im Internet und ein wenig try&error bin ich dann dahinter genommen wie es funktioniert.

Werte von FHEM las ich über HTTP GET aus:
http://<fhemIP>:8083/fhem?cmd=xmllist%20<device>%20&XHR=1
Meine Steuer Befehle setzte ich über HTTP POST ab:
http://<fhemIP>:8083/fhem?cmd=set%20<device>%20<befehl>&XHR=1

Um den CSRF Token zu bekommen führe ich jetzt eine HTTP GET aus.
Aus der Antwort suche ich mir im Header die Zeile X-FHEM-csrfToken: fhem_xxxxxxxxxxx heraus und Speicher den Token in eine Variable.
GET muss dann wie folgt erweitert werden:
http://<fhemIP>:8083/fhem?cmd=xmllist%20<device>%20&XHR=1&fwcsrf=<token>
Und bei HTTP POST:
http://<fhemIP>:8083/fhem?cmd=set%20<device>%20<befehl>&XHR=1&fwcsrf=<token>

Dank Tasker ist das zum Glück kein Problem, eine kleine Routine einzubauen, die den Token aus dem Header extrahiert, so dass er für weiter POST und GET Befehle genutzt werden kann.

Probleme sehe ich aber bei anderen Anwendungen, die über HTTP URLs FHEM steuern/triggern, wie zum Beispiel der Alarm Server bei Webcam's http://wiki.instar.de/index.php/Alarm_Server_Funktion
Hier führt denke keine Möglichkeiten am deaktivieren von csrfToken vorbei.

Oder kennt hier jemand eine andere Möglichkeit?

Gruß Schlimbo

KernSani

Hi,

ich bin aktuell etwas zurückhaltend mit einem update, da offensichtlich einige Module und Funktionen mit dem Token (noch) nicht zurecht kommen.
Aus meiner Sicht würde es Sinn machen:

  • In einem zentralen Forumseintrag (oder evtl. Wiki) eine Übersicht zu erstellen, welche Module aktuell nicht mit CSRF können, evtl. mit Verweis auf Forumsbeitrag in dem Workaround/Stand der Anpassung (durch Mainainer) kommuniziert wird
  • EIn kleines How-To mit den Optionen, wie Bastellösungen csrfToken nutzen/umgehen können

Denkt ihr das würde Sinn machen? Ich würde dann heute Abend mal anfangen die Wiki-Liste zu basteln... 

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

betateilchen

Zitat von: KernSani am 21 Februar 2017, 15:40:51
Denkt ihr das würde Sinn machen?

Nein.

Zitat von: KernSani am 21 Februar 2017, 15:40:51
Ich würde dann heute Abend mal anfangen die Wiki-Liste zu basteln... 

Bitte nicht. So eine Liste kann nie wirklich aktuell sein und verwirrt mehr, als dass sie nützt.

Einfach ein paar Tage Geduld haben, die meisten Entwickler sind ja schon dabei, ihre Module entsprechend anzupassen (sofern nicht ohnehin schon geschehen)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

KernSani

Zitat von: betateilchen am 21 Februar 2017, 19:23:50
Bitte nicht. So eine Liste kann nie wirklich aktuell sein und verwirrt mehr, als dass sie nützt.
Bei genauerem Nachdenken stimme ich dir zu... mein Gedanke war, jeden Abend durch die changelogs der betroffenen Module zu gehen und die Liste entsprechend zu aktualisieren. Mittlerweile halte ich das selbst für keine so gute Idee mehr.

Einen Wiki-Artikel, wie Shellskripte etc... an das token kommen fände ich aber immernoch hilfreich...

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

sinus61

Ich habe in einem Logfile eines Dummy das Attribut eventOnThreshold auf 1 gesetzt. Jetzt bekomme ich immer wenn in das Log geschrieben wird 2 Fehlermeldungen im Fhem Log:

2017.02.23 14:15:11 3: FHEMWEB WEB CSRF error:  ne fhem_38545271019889.6. For detals see the csrfToken FHEMWEB attribute
2017.02.23 14:15:17 3: FHEMWEB WEB CSRF error:  ne fhem_38545271019889.6. For detals see the csrfToken FHEMWEB attribute


Wenn ich eventOnThreshold lösche geht es ohne Fehler. Kann man das irgendwie abstellen ohne in WEB das Attribut auf none zu setzen?

rudolfkoenig

ZitatIch habe in einem Logfile eines Dummy das Attribut eventOnThreshold auf 1 gesetzt.
Ich hoffe nur fuer Demozwecke, sonst ist das nur eine sinnlose FHEM-Quaelerei.

ZitatJetzt bekomme ich immer wenn in das Log geschrieben wird 2 Fehlermeldungen im Fhem Log
Aus theoretischen  Gruenden halte ich die Ursache-Wirkung fuer ausgeschlossen, aber nur um auf Nummer sicher zu gehen: habe dummy angelegt, FileLog dazu, Attribut gesetzt, dummy Event erzeugt -> keine Fehlermeldung.
Ja, Datei wird geschrieben, und es werden 2 Events produziert, eins fuer dummy, eins fuer FileLog.

sinus61

Ok, ich hab es. Tatsächlich wartet hier auf 2 Tablets mit Ftui ein Widget auf dieses Event und produziert dann den Fehler. Wenn eventOnThreshold nicht gesetzt ist passiert da eben auch nichts.

Schlimbo

Hallo zusammen,
muss hier noch mal fragen:
Zitat von: Schlimbo am 20 Februar 2017, 21:36:46
Um den CSRF Token zu bekommen führe ich jetzt eine HTTP GET aus.
Aus der Antwort suche ich mir im Header die Zeile X-FHEM-csrfToken: fhem_xxxxxxxxxxx heraus und Speicher den Token in eine Variable.
Mit meiner Variante um den Token zu bekommen, wird der erste Aufruf ja immer abgewiesen, weil er ohne Token durchgeführt wird.
Dadurch bekomme ich dann logischerweise einen Log Eintrag:
FHEMWEB WEB CSRF error:  ne fhem_492xxxxxxxxx. For detals see the csrfToken FHEMWEB attribute
Gibt es noch einen anderen/eleganteren weg um an den Token zu kommen,  ohne Log Eintrag?

Gruß Schlimbo

CoolTux

Du könntest einen festen Token vergeben.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Schlimbo

Ja, das hatten wir im andern Thread ja schon mal.
Seh das aber auch wie Betateilchen:
Zitat von: betateilchen am 21 Februar 2017, 11:52:29
Ein Token fest vorzugeben macht für mich eigentlich keinen Sinn, dann kann man es auch gleich abschalten.
Würde den random Token schon am liebsten weitere nutzen.
Schön wäre eine URL, die nur den Token zurück liefert ohne Log Eintrag.
zum Beispiele so etwas:
http://<fhemIP>:8083/fhem?cmd=xmllist%20getcsrfToken%20&XHR=1
Weiß natürlichen nicht ob es möglich ist so etwas zu implementieren!?

rudolfkoenig

Hole irgendetwas ohne cmd= von FHEM ab, z.Bsp. die Einstiegsseite.

CoolTux

Zitat von: rudolfkoenig am 24 Februar 2017, 19:38:19
Hole irgendetwas ohne cmd= von FHEM ab, z.Bsp. die Einstiegsseite.

Stimmt das hattest Du ja in dem anderen Thread vor paar Tagen auch erwähnt. Man(n) wird halt alt  ???
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Schlimbo

Danke für den Tipp.
Denke dann ist folgender Aufruf am besten geeignet:
http://<fhemIP>:8083/fhem?XHR=1
Die Antwort soll ja schnellstmöglich ankommen (wenig Datenübertragung).
Durch XHR=1 wird ja dann wirklich nur der Header übertragen.

Ralf W.

#22
Hallo,

wenn "Commandref" aus FHEM aufgerufen wird, dann funktionieren einige Einträge (z.B. attr) und andere nicht (z.B. fheminfo) und im Log erscheint dieser CSRF error.

Einfach ein paar Tage warten?

MfG

PS: Und "Komplette Doku laden" überschwemmt das Log mit Fehlermeldungen.
http://twitter.com/RWausD
Schon gewusst, dass Haarausfall zu einer Glatze führen kann?

FHEM: NUC7PJYH2, Ubuntu Server 22.04.2 LTS, HMCCU - RaspberryMatic, DE ConBee II, diverse Sensoren und Aktoren.

rudolfkoenig

ZitatEinfach ein paar Tage warten?
Jenachdem, bis morgen, oder es hilft nicht.

Zur Klarstellung:
- das Problem tritt auf, wenn man im Browser die modular-Version der Seite laedt (attr global commandref modular), FHEM neu startet, und danach ohne reload oder nach einfachem reload  (Ctrl-R) die Seite neu laedt. Nach einem "kompletten" reload (Shift-Ctrl-R) funktioniert es.
- da nach einem FHEM-Neustart ein neues CSRF generiert wird, bleibt ein reload weiterhin noetig, ich habe es aber geaendert, so dass jetzt eine einfaches reload reicht.

Ralf W.

#24
Hallo Rudi,

danke, Tastenkombination hat geklappt. Dann warte ich auf das Update morgen. Beim Firefox hoffe ich, dass durch die  Einstellung browser. cache. check_doc_frequency = 1 alles wieder automatisch geht.

MfG
http://twitter.com/RWausD
Schon gewusst, dass Haarausfall zu einer Glatze führen kann?

FHEM: NUC7PJYH2, Ubuntu Server 22.04.2 LTS, HMCCU - RaspberryMatic, DE ConBee II, diverse Sensoren und Aktoren.

rudolfkoenig

Nach dem update morgen sollte gar kein refresh mehr notwendig sein, fhemdoc_modular.js versucht ab sofort beim Fehler einen neuen Token zu holen. Die Fehlermeldung im FHEM-Log wird aber weiterhin erscheinen, habe momentan keine Idee, wie ich das wegkriegen soll ausser komplett ausbauen, aber das ist z.Zt. noch nicht moeglich.

Hadl

Hallo zusammen,
ich habe ein ähnliches Problem, jedoch beim normalen Event Monitor.
Da wird scheinbar der Token richtig übergeben, aber das '+' im Exponenten geht verloren.
Im log schaut das dann so aus:
FHEMWEB WEB CSRF error: fhem_1.04140199466189e 15 ne fhem_1.04140199466189e+15. For detals see the csrfToken FHEMWEB attribute

rudolfkoenig

Die e+ Notation ist wohl selten genug, dass ich es nicht generiert bekomme, deswegen ist das Probem mir nicht aufgefallen.

Ich habe jetzt ein paar kleine Aenderungen durchgefuehrt, die solche Problemfaelle vermeiden sollten.
- aus dem "random" Token wird alles entfernt, was nicht a-z_0-9 ist, und es faengt jetzt mit csrf_ an (und nicht mehr mit fhem_)
- fhemweb.js fuegt jetzt den Token via encodeURIComponent hinzu (damit sollte das + richtig uebertragen werden)
- 01_FHEMWEB/fhemweb.js akzeptiert auch 0 als csrfToken. 0 war bisher teilweise synonym fuers abschalten, und hat wg. FW_csrfRefresh eine Endlosschleife bewirkt. 0 ist ein ganz normaler Token, und hat keine Sonderbedeutung.
- wenn aus anderen Gruenden eine FW_csrfRefresh-Endlosschleife auftreten sollte, wird es jetzt unterbunden.

Update wie immer morgen ab 8.

Skram

Hmm, das Abstellen mit "none" scheint bei mir nicht zu funktionieren.


define WEB FHEMWEB 8083 global
attr WEB confirmDelete 0
attr WEB csrfToken none
attr WEB endPlotNow 1


Und wenn ich im Browser die URL "http://fhem:8083/fhem?XHR=1" aufrufe, bekomme ich eine leere Antwort und finde im Log

2017.03.03 19:56:16 4: Connection accepted from WEB_192.168.0.23_52177
2017.03.03 19:56:16 4: WEB_192.168.0.23_52176 GET /fhem?cmd=jsonlist2&XHR=1; BUFLEN:0
2017.03.03 19:56:16 3: FHEMWEB WEB CSRF error:  ne csrf_429984230293756. For detals see the csrfToken FHEMWEB attribute
2017.03.03 19:56:16 4: name: /fhem?cmd=jsonlist2&XHR=1 / RL:20 / text/html; charset=UTF-8 / Content-Encoding: gzip


Was habe ich übersehen? Bin dankbar für Tipps.

(fhem.pl:13560/2017-03-01 perl:5.020002 os:linux user:fhem pid:25683)

rudolfkoenig

ZitatWas habe ich übersehen? Bin dankbar für Tipps.

Das angezeigte Token csrf_429984230293756 kann nur entstehen, wenn man csrfToken nicht definiert hat, auf random oder genau diesen Wert gesetzt hat. Mit none wird sie nicht gesetzt und nicht geprueft. Habs gerade nochmal getestet.

Ich gehe davon aus, dass die gezeigte Konfiguration nicht zum Log passt, entweder weil csrfToken nachtraeglich entfernt wurde, oder weil es fuer eine andere FHEM-Instanz gilt.
Kannst du bitte im Problemfall
list .* CSRFTOKEN
und
list .* csrfToken
ausfuehren, und die Ausgabe hier zeigen?

Skram

Woher kommt denn das Token in Großbuchstaben?


define WEB FHEMWEB 8083 global
attr WEB confirmDelete 0
attr WEB csrfToken none
attr WEB endPlotNow 1

list .* CSRFTOKEN
WEB csrf_311697085119951

list .* csrfToken
WEB none



2017.03.04 13:49:30 1: UPD FHEM/01_FHEMWEB.pm
...
2017.03.04 18:55:38 0: Featurelevel: 5.8
2017.03.04 18:55:38 0: Server started with 281 defined entities (fhem.pl:13593/2017-03-04 perl:5.020002 os:linux user:fhem pid:6406)
2017.03.04 19:23:21 3: FHEMWEB WEB CSRF error:  ne csrf_311697085119951. For detals see the csrfToken FHEMWEB attribute


Eine zweite Serverinstanz gibt es nicht:
root@fhem:~# ps -ax | grep -i fhem
6406 ?        S      0:06 /usr/bin/perl fhem.pl fhem.cfg
6641 pts/0    S+     0:00 grep -i fhem

Benni

Zitat von: Skram am 04 März 2017, 19:39:03
Woher kommt denn das Token in Großbuchstaben?

Das ist ein Internal von FHEMWEB.

Skram

Was mache ich dann falsch? Das eine habe ich auf none gesetzt, das andere ist ein Internal und ich kann es nicht beeinflussen.
Der Aufruf von
http://fhem:8083/fhem?cmd=jsonlist2&XHR=1
meldet aber o.a. Fehler im Log und liefert eine leere Seite.   :(

CoolTux

Zitat von: Skram am 04 März 2017, 22:26:37
Was mache ich dann falsch? Das eine habe ich auf none gesetzt, das andere ist ein Internal und ich kann es nicht beeinflussen.
Der Aufruf von
http://fhem:8083/fhem?cmd=jsonlist2&XHR=1
meldet aber o.a. Fehler im Log und liefert eine leere Seite.   :(

Wenn Du das Attribut schon auf none gesetzt hast, dann mach mal ein neustart.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Benni

Mach mal ein save und dann ein shutdown restart

Edit: Leon war etwas schneller  ;D

Skram

#35
Danke für Eure Antworten! :D
Das wollte ich mit dem o.a. Log-Ausschnitt anzeigen. Einen Neustart habe ich durchgeführt, es hilft aber leider nichts.


2017.03.04 22:39:49 0: Featurelevel: 5.8
2017.03.04 22:39:49 0: Server started with 281 defined entities (fhem.pl:13593/2017-03-04 perl:5.020002 os:linux user:root pid:7639)
...
2017.03.04 22:43:37 3: FHEMWEB WEB CSRF error:  ne csrf_341766229578767. For detals see the csrfToken FHEMWEB attribute


EDIT:
Wenn ich bei Server-Start "csrfToken none" gesetzt habe, bekomme ich o.a. Fehler.
Wenn ich im laufenden Betrieb in der Weboberfäche das Attribut auf "1" setze und danach wieder auf "none", dann geht's.

rudolfkoenig

ZitatWenn ich bei Server-Start "csrfToken none" gesetzt habe, bekomme ich o.a. Fehler.
Ich habe das versucht nachzustellen, ohne Erfolg. Da ich gestern noch etliches gefixt habe: kannst du bitte das Ganze nach einem update erneut testen?

Skram

2017.03.05 11:31:59 1 : UPD FHEM/01_FHEMWEB.pm

Im ersten Anlauf sieht's jetzt gut aus. Nach einem Neustart ist "CSRFTOKEN" nicht gesetzt und
http://fhem:8083/fhem?cmd=jsonlist2&XHR=1 funktioniert.

Vielen lieben Dank!  :D

fhemler



Zitat von: Schlimbo am 20 Februar 2017, 21:36:46
Hallo zusammen,
Ich hatte auch das Problem, dass meine Steuerung über die Android App Tasker nicht mehr funktioniert hatte.
Nach ein wenig Recherche im Internet und ein wenig try&error bin ich dann dahinter genommen wie es funktioniert.

Werte von FHEM las ich über HTTP GET aus:
http://<fhemIP>:8083/fhem?cmd=xmllist%20<device>%20&XHR=1
Meine Steuer Befehle setzte ich über HTTP POST ab:
http://<fhemIP>:8083/fhem?cmd=set%20<device>%20<befehl>&XHR=1

Um den CSRF Token zu bekommen führe ich jetzt eine HTTP GET aus.
Aus der Antwort suche ich mir im Header die Zeile X-FHEM-csrfToken: fhem_xxxxxxxxxxx heraus und Speicher den Token in eine Variable.
GET muss dann wie folgt erweitert werden:
http://<fhemIP>:8083/fhem?cmd=xmllist%20<device>%20&XHR=1&fwcsrf=<token>
Und bei HTTP POST:
http://<fhemIP>:8083/fhem?cmd=set%20<device>%20<befehl>&XHR=1&fwcsrf=<token>

Dank Tasker ist das zum Glück kein Problem, eine kleine Routine einzubauen, die den Token aus dem Header extrahiert, so dass er für weiter POST und GET Befehle genutzt werden kann.

[...]

Gruß Schlimbo


Hallo,

danke schon mal für deinen post. Aber leider funktioniert es bei mir nicht.
Ich habe den Token in der Variable %csrftoken abgespeichert. Aber der weitere Aufruf über HTTP POST (oder auch GET) funktioniert nicht. Immer die bekannte Fehlermeldung im Log.

Hier mal mein HTTP POST:
Server: http://fhem.fritz.box:8083
Path: fhem
Data/File: cmd=%par1&XHR=1&fwcsrf=%csrftoken

%par1 ist der an den Task übergebene Parameter (z.B. set <device> toggle)
Ich habe auch schon die Leerzeichen in %par1 durch %20 ersetzt, das Ergebnis bleibt aber gleich.
Ohne Token hatte es auch vor Version 5.8 schon funktioniert.

Hat noch jemand eine Idee?

Gruß
fhemler



rudolfkoenig

Ob und was gesendet wird, solltest du im FHEM-Log sehen.
Wenn das Extrahieren des tokens schwierigkeiten bereitet kann man auch mit einem festen Token versuchen: das ist nicht wesentlich unsicherer als ein zufaelliger, ist nur nicht praktikabel fuer die Distribution.

fhemler

Zitat von: rudolfkoenig am 30 März 2017, 09:45:57
Ob und was gesendet wird, solltest du im FHEM-Log sehen.
Wenn das Extrahieren des tokens schwierigkeiten bereitet kann man auch mit einem festen Token versuchen: das ist nicht wesentlich unsicherer als ein zufaelliger, ist nur nicht praktikabel fuer die Distribution.
Vielen Dank für den Hinweis aufs Log. Da hatte ich zwar schon rein geschaut, aber dein Hinweis hat mich auf die Idee gebracht das verbose Level mal höher zu setzen.
Und irgendwie sah der Aufruf tatsächlich ein bisschen komisch aus.
Nach etwas studieren der Tasker Hilfe habe ich dann herausgefunden, dass man bei HTTP GET mehrere Attribute durch einen Zeilenumbruch trennen muss und nicht per & aneinander hängt (das macht Tasker dann beim Aufruf).
Bei HTTP POST ist es dasselbe, nur halt im Feld 'Data / File'.

Also vielen Dank nochmal! Jetzt kann ich meine Geräte endlich wieder per widget steuern.

inter79

#41
Hallo,

versuche mich gerade am ESP8266 nach dem vorhandenen Tutorial zu integrieren. Leider komm ich mit dem Fehler überhaupt nicht klar:

FHEMWEB WEB CSRF error: csrf_858961678588965 ne csrf_246023380465126 for client WEB_192.168.1.201_63794 / command shutdown restart. For details see the csrfToken FHEMWEB attribute.


In der Datei fhem_bh1750.lua ist folgende Zeile:
conn:send('GET /fhem?cmd=setreading%20esp8266temp%20state%20' ..luxi.. '&XHR=1\r\n HTTP/1.1\r\nHost: www.local.lan\r\n".."Connection: keep-alive\r\nAccept: */*\r\n\r\n"')



Muss nun die Zeile in der Lua abgeändert werden? Oder muss ich auch in der Fhem etwas anderes Konfigurieren?
Den CSRFToken habe  ich in der WEB gefunden.


rudolfkoenig

csrfToken dient dazu, um gegen CSRF Atacken sich zu wehren.
Sie wird nach jedem FHEM-Start automatisch generiert, es sei denn, man setzt sie explizit.
Wenn man FHEM via HTTP fernsteuern moechte, dan empfiehlt sich das explizite Setzen.

D3ltorohd

So, ich hänge mich hier mal mit an.

Ich weiß nicht, habe ich die Fehlermeldung schon länger ::

2019.10.24 12:08:13 3: FHEMWEB WEB CSRF error: csrf_104345683644172 ne csrf_148832911104462 for client WEB_192.168.178.20_54197 / command shutdown restart. For details see the csrfToken FHEMWEB attribute.

Oder erst seitdem, seit ich vorher OpenHab2 deinstalliert habe und den Rest mit Autoremove entfernt habe. Vllt wurden hier Pakete die FHEM mit nutzt auch entfernt. Vorher ist mir der Eintrag in der Log nicht aufgefallen, jetzt steht er ja schon recht häufig drin.

Ich nutze FHEM nur lokal, über PC und Tablet. Ich möchte es später nicht von aussen steuerbar machen. ? Brauche ich dann dieses Token ? Oder kann ich es abschalten ? Oder was muss ich genau tun um es an zu lassen und diese Fehlermeldung weg zu bekommen ?

Hab mir mal die Wiki durchgelesen, aber steig da nicht wirklich durch.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

rudolfkoenig

ZitatBrauche ich dann dieses Token ?
Wenn du sicherstellen kannst, dass mit keinem Browser, mit dem man auf FHEMWEB zugreift, im Internet unterwegs ist, dann nicht.

Bei fehlendem csrfToken kann beim Besuch einer schlechtgelaunten Internetseite dein FHEM-Server zu einem Bot umgebaut werden, und das wird irgendwannmal mir angelastet. Dass die Internetseite auch deine FHEM-Geraete einschalten/loeschen/etc kann, das ist mir dabei weniger wichtig :)

D3ltorohd

#45
Um sicher zu gehe, indem Fall mit Token.

Ich komm da aber immer noch nicht so klar mit. Sorry.

Also das token wird gebraucht damit mein Browser damit identifiziert wird und FHEM steuern kann ?

Weshalb kann ich dennoch alles steuern vom Browser aus, mit dieser Token Geschichte hab ich noch nie was gemacht.

Und warum fällt mir der Fehler erst jetzt auf ? Nachdem ich OH2 deinstalliert habe und die Pakete bereinigen lies ?

Nutze z.b. Tablet UI, damit kann ich soweit alles steuern was ich an Aktoren habe.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

Otto123

Zitat von: D3ltorohd am 24 Oktober 2019, 12:20:47
Hab mir mal die Wiki durchgelesen, aber steig da nicht wirklich durch.
Hast Du da bitte Details? Ich habs an der Stelle hauptsächlich geschrieben und würde es gern besser machen. ;)

Deine Medlung (vermute ich) kommt beim Neustart von FHEM wenn Du mit dem Browser auf eine Detail Seite warst und nach dem Neustart einfach einen Refresh machst (oder der Browser automatisch)

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

D3ltorohd

Zitat von: Otto123 am 24 Oktober 2019, 14:00:16
Hast Du da bitte Details? Ich habs an der Stelle hauptsächlich geschrieben und würde es gern besser machen. ;)

Deine Medlung (vermute ich) kommt beim Neustart von FHEM wenn Du mit dem Browser auf eine Detail Seite warst und nach dem Neustart einfach einen Refresh machst (oder der Browser automatisch)

Gruß Otto

Gleich im ersten Teil steht ::

Dieses Feature erhöht die Sicherheit, führt aber dazu, dass man nicht mehr mit einem einfachen http Link auf das FHEMWEB zugreifen kann.

Ich muss aber einfach nur in meinem Browser folgendes http://192.168.178.30:8083/fhem eingeben und komme direkt auf das Interface. Hier kann ich auch die Aktoren schalten ?

Über FTUI kann ich auch steuern. Mit sowas habe ich noch nicht gearbeitet ? http://localhost:8083/fhem?cmd=set%20Office%20on

Und mit sowas schon gleich gar nicht :: curl -s -D - 'http://localhost:8083/fhem?XHR=1' | awk '/X-FHEM-csrfToken/{print $2}'

Daher zumindest für ich verwirrend, da ich keine Ahnung habe, was da passiert und wo das ein zu geben ist.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

Otto123

#48
Es geht ja nicht um die interaktive "Klick" Arbeit mit dem Browser, der macht das Transparent (bis auf deinen Fall)
Es geht wirklich um den Link (Beispiel) der direkt durch den Klick darauf etwas auslöst!

In vielen alten Anleitungen steht:
Mann kann von jedem x beliebigen System (ohne Browser, ohne FHEM) einen http Aufruf machen:
http://localhost:8083/fhem?cmd=set%20Office%20on
und damit den Aktor "Office" auf on schalten.
Das geht eben nicht mehr...

Ok die Einleitung enthält keine Prosa, aber wenn man bis zum Ende liest steht doch alles mit Beispielen da "wo und wie" das verwendet werden kann?
Und in den 3 Links zum Schluss findest Du doch auch etwas "Prosa"?
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

D3ltorohd

Ich hab nicht bis zum Ende gelesen  :-[ Da ich oben schon ausgestiegen bin.

Aber indem Fall sollte mich das nicht betreffen und kann ich so erst mal ignorieren, wenn der Logeintrag so erst mal nicht weiter stört oder irgendwas nicht richtig funktioniert.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

Otto123

Ich habe die Einleitung und Struktur angepasst, damit Du mit gutem Gewissen aussteigen kannst. Kannst ja nochmal drüberlesen und Feedback geben ;)

Es sollte bei Dir aber normalerweise nicht auftauchen! Einzige Ausnahme: Du stehst auf eine Seite mit CsrfToken hinten dran (soviele gibt es im FHEMWEB da nicht mehr), drückst auf shutdown restart und dann bleibt der Browser so stehen und nach einer Minute (oder so) drückst Du auf refresh (oder der Browser macht es allein)

Mein nachvollziehbares Beispiel:
ich habe ein MQTT Device offen, drücke auf das grüne MQTT2_DEVICE in der Zeile TYPE es öffnet sich eine list Ansicht und in der Browser Zeile steht:
hostname:8083/fhem?cmd=list%20TYPE=MQTT2_DEVICE&fwcsrf=csrf_196525024154371
dann shutdown restart in die FHEM Kommandozeile und zack kommt: Diese Seite hat einen Fehler - nach dem Neustart und wie beschrieben den Fehler.
2019.10.24 15:34:40 3: FHEMWEB WEB CSRF error: csrf_196525024154371 ne csrf_929924752869341 for client WEB_192.168.56.55_2869 / command list TYPE=MQTT2_DEVICE. For details see the csrfToken FHEMWEB attribute.
Wenn es bei Dir an andere Stelle und häufiger ist??? ?

Aber was mir gerade auffällt: Du hast den cmdalias mit Systembefehle ? In der Art?
defmod Systembefehle weblink cmdList Restart:Restart-Fhem:shutdown+restart Restart:Restart-System:reboot Update:Update-Check:update+check Update:Update-Now:update Shutdown:Shutdown-System:halt

da ist das quasi zu erwarten :)

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

D3ltorohd

#51
Ja das kann sein, das ist ein Style, da war das mit dem Update, Restart usw mit eingebaut. Aber woher weißt du das ich das so habe ? Hab ich das gepostet ?

Dann kommt der Fehler daher ? Also müsste man da was ändern, weil hier eben diese Befehle geschickt werden über http ?

Jetzt hab ich auf jeden Fall mehr verstanden im Wiki !! Liest sich gut.

Indem Fall kommt, das auch durch Refresh drücken nach einem Restart, das mache ich meistens so.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

Otto123

Deine Fehlermeldung:
Zitat2019.10.24 12:08:13 3: FHEMWEB WEB CSRF error: csrf_104345683644172 ne csrf_148832911104462 for client WEB_192.168.178.20_54197 / command shutdown restart. For details see the csrfToken FHEMWEB attribute.
Ich habe bei meiner Fehlermeldung etwas ähnliches gesehen:
Zitat2019.10.24 15:34:40 3: FHEMWEB WEB CSRF error: csrf_196525024154371 ne csrf_929924752869341 for client WEB_192.168.56.55_2869 / command list TYPE=MQTT2_DEVICE. For details see the csrfToken FHEMWEB attribute.

Wenn man shutdown restart (habe ich ja auf der Seite gemacht) kommt nicht das man shutdown gemacht hat. ;)
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

D3ltorohd

Ok, dann weiß ich aber wohl jetzt wo die Meldung her kommt und ist so nicht weiter tragisch, die Befehle funktionieren, somit sollte das für mich erst mal erledigt sein. Vielen Dank !!
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

Otto123

Zitat von: D3ltorohd am 24 Oktober 2019, 16:35:18
Indem Fall kommt, das auch durch Refresh drücken nach einem Restart, das mache ich meistens so.
Ich habe mir angewöhnt genau das nicht zu machen sondern auf das FHEM Symbol zu klicken, da ist alles gut.

Das mit refresh im Browser kann nämlich auch in Hose gehen: Du tippst backup ein und der Browser wiederholt den Befehl ;) oder so
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