Neue Version von HTTPMOD mit neuen Features zum Testen

[frank]

Gibt es dafür irgendeine (logische) Erklärung?

, na hoffentlich.

kann es an den cookies liegen?

[Vize]

Hallo frank,

wie muss ich das verstehen?

Mein Halb-Wissen:
Das sind doch session-cookies, oder?
Die werden ja dann z.B. nach jedem (Komplett)-Schließen des Browsers neu generiert beim nächsten Aufruf der Seite, oder?

Bei meinem funktionierenden HTTPMOD-Device stehen in den internals aber von Beginn an dieselben cookies, und diese verändern sich auch nicht...z.B. nach einem disable 1 -> disable 0 des devices...

Hast du dazu eventuell eine Lösung, wie ein zweites device dieselbe Seite bzw. die andere Unterseite "anzapfen" kann?

Dank und Gruß
Andreas

[frank]

Mein Halb-Wissen:

dann weisst du ja schon mehr als ich. 
ist halt nur so eine idee, da ja sonst alles identisch sein soll.

Das sind doch session-cookies, oder?
Die werden ja dann z.B. nach jedem (Komplett)-Schließen des Browsers neu generiert beim nächsten Aufruf der Seite, oder?

vielleicht auch erst mit explizitem logout und/oder dem ablauf des cookies.
manchmal gibt es ja eine option wie "angemeldet bleiben".

Bei meinem funktionierenden HTTPMOD-Device stehen in den internals aber von Beginn an dieselben cookies, und diese verändern sich auch nicht...z.B. nach einem disable 1 -> disable 0 des devices...

da hattest du doch auch enableCookies gesetzt, oder? ich denke, dass sie dann eventuell nach einem restart von fhem erneuert werden, falls sie diesen nicht überleben.

aber, wie gesagt, habe ich mit anmeldungen/cookies noch keine erfahrungen.

[Vize]

Alles klar, danke dir trotzdem nochmal für deine Hilfe/Anmerkungen...

Gruß
Andreas

[Vize]

Hallo,

für alle, die das SENEC-Portal abfragen möchten, bitte die Editierung hier beachten...ist mir erst aufgefallen, als das HTTPMOD-Device nach einem Neustart von FHEM keine Daten mehr lieferte...

Gruß
Andreas

[Vize]

Hallo,

leider zu früh gefreut, das Ganze funktioniert so nur solange, wie man im Online Portal von SENEC per browser angemeldet ist und die dabei generierten cookies nutzt. Loggt man sich aus dem SENEC-Portal aus, können auch keine Daten mehr per HTTPMOD-Device abgeholt werden.

Was mir auffiel:
Im alten, funktionierenden device waren die Internals "HTTPCookies" und "Httpcookiehash" gefüllt. Dies ist nach dem Neustart von FHEM nun nicht mehr so...

Ich habe leider keine Ahnung mehr, wie ich es damals geschafft habe, diese zu füllen.

Vielleicht weiß ja jemand, woran es liegen könnte bzw. kann mir einen Tipp geben....

Danke schonmal im Voraus!

Gruß
Andreas

[StefanStrobel]

Hallo Andreas,

Nur um ein paar Trivialitäten auszuschließen:
Verwendest Du die neueste Version von HTTPMOD aus diesem Thread oder hast Du inzwischen mal ein fhem update gemacht und damit evt. wieder die alte Version bekommen?

Poste doch bitte nochmal Deine aktuelle Konfiguration als Ausschnitt aus der fhem.cfg

Gruss
    Stefan

[betateilchen]

Danke für das alignTime

[Vize]

Hallo Stefan,

nein, kein update zwischendurch gefahren...

Version HTTPMOD:
98_HTTPMOD.pm 11002 2016-03-05 19:39:06Z ststrobel

Auszug aus fhem.cfg

Code Auswählen Erweitern

define httpmod_test_2 HTTPMOD https://mein-senec.de/monitoring/json/status/getstatusoverview.php?id=XXX 60
attr httpmod_test_2 userattr requestHeader1 sid1Data sid1Header1 sid1Header2 sid1URL
attr httpmod_test_2 disable 0
attr httpmod_test_2 enableCookies 1
attr httpmod_test_2 extractAllJSON 1
attr httpmod_test_2 reAuthRegex {"success":false}
attr httpmod_test_2 requestHeader1 Cookie: ies_sessid=57435509b0fae;; ies_secret=rINdv9i0HwCRRWf3
attr httpmod_test_2 sid1Data {"email":"meine@email.de","password":"geheim"}
attr httpmod_test_2 sid1Header1 Content-Type: application/json
attr httpmod_test_2 sid1Header2 Accept: */*
attr httpmod_test_2 sid1URL https://mein-senec.de/monitoring/json/auth/login.php

Damit kommen aktuell die Daten...bis ich mich im browser aus der Seite wieder auslogge... 

Gruß
Andreas

[brembs]

***EDIT***
Folgendes Attribut muss noch unbedingt gesetzt werden, hatte ich irgendwie vergessen:

Code Auswählen Erweitern

requestHeader1  Cookie: ies_sessid=<cookie1>; ies_secret=<cookie2>

Die jeweils entsprechende Bezeichnung von <cookieX> kann man mit burp oder den Entwicklertools der browser ermitteln.

***ENDE EDIT***

Also diese request header werden mit jeder Session als response header mit "Set-Cookie" beim login neu gesetzt. Das kann also nicht wirklich funktionieren. So wie ich das verstanden habe, sollte "enableCookies" das machen. Frage ist, warum tut es das nicht?

[brembs]

@Stefan & @Vize:

Kann Andreas' Ergebnis 100% reproduzieren. Bekomme genau das gleiche Verhalten. Die Cookies, die mit jeder neuen Session gesetzt werden, kommen irgendwie nicht durch. Wenn man sie von Hand auf die Session setzt, die man gerade im Browser hat, dann geht es natürlich - aber nur solange wie man im Browser eingeloggt ist. Irgendwie müssten also die Cookies in den request header - wie macht man das?

[StefanStrobel]

Hallo Andreas,

Bitte probier es doch nochmal mit der Modulversion, die ich zuletzt hier im Forum gepostet habe. Die ist neuer und hat auch einen Fehler beim Cookie-Handling behoben.
Wenn es damit auch nicht klappt, wäre ein Log-Auszug bei verbose 5 hilfreich.
Das requestHeader1 Attribut muss auf jeden Fall raus. Dafür ist enableCookies da.

Gruß
     Stefan

[Vize]

Hallo Stefan,

leider kein Erfolg mit deinem Tipp der neueren Version von HTTPMOD...

Wobei, deine Version aus post #172 zeigt das hier als Version, und das ist älter, als bei der, die ich vorher benutzt habe:

Code Auswählen Erweitern

98_HTTPMOD.pm  8282 2015-03-24 20:36:58Z ststrobel

Hier dann noch der Log-Auszug mit verbose 5:

Code Auswählen Erweitern

2016.05.24 17:36:55 4: httpmod_test_2: GetUpdate called (update)
2016.05.24 17:36:55 4: httpmod_test_2: update timer modified: will call GetUpdate in 60.0 seconds at 2016-05-24 17:37:55
2016.05.24 17:36:55 5: httpmod_test_2: AddToQueue called, initial send queue length : 0
2016.05.24 17:36:55 5: httpmod_test_2: AddToQueue adds type update to URL https://mein-senec.de/monitoring/json/status/getstatusoverview.php?id=XXX, no data, no headers, retry 0
2016.05.24 17:36:55 5: httpmod_test_2: HandleSendQueue called, qlen = 1
2016.05.24 17:36:55 4: httpmod_test_2: HandleSendQueue sends request type update to URL https://mein-senec.de/monitoring/json/status/getstatusoverview.php?id=XXX, No Data, No Header,
timeout 2
2016.05.24 17:36:55 4: HttpUtils url=https://mein-senec.de/monitoring/json/status/getstatusoverview.php?id=XXX
2016.05.24 17:36:56 4: https://mein-senec.de/monitoring/json/status/getstatusoverview.php?id=XXX: HTTP response code 403
2016.05.24 17:36:56 4: HttpUtils https://mein-senec.de/monitoring/json/status/getstatusoverview.php?id=XXX: Got data, length: 1
2016.05.24 17:36:56 5: httpmod_test_2: Read callback: request type was update retry 0,
Header: HTTP/1.1 403 Forbidden
Date: Tue, 24 May 2016 15:36:56 GMT
Server: Apache/2.4.10 (Debian)
Expires: Tue, 24 May 2016 14:36:56 GMT
Content-Length: 1
Content-Type: application/json,
Body:
no error
2016.05.24 17:36:56 5: httpmod_test_2: looking for Cookies in HTTP/1.1 403 Forbidden
Date: Tue, 24 May 2016 15:36:56 GMT
Server: Apache/2.4.10 (Debian)
Expires: Tue, 24 May 2016 14:36:56 GMT
Content-Length: 1
Content-Type: application/json
2016.05.24 17:36:56 3: httpmod_test_2: error while parsing JSON data: malformed JSON string, neither array, object, number, string or atom, at character offset 1 (before "(end of string)") at (eval 33460) line 1.

2016.05.24 17:36:56 5: httpmod_test_2: ExtractSid called, context reading, num
2016.05.24 17:36:56 5: httpmod_test_2: CheckAuth is checking buffer with ReAuthRegex {"success":false}
2016.05.24 17:36:56 3: httpmod_test_2: no parsed JSON structure available
2016.05.24 17:36:56 5: httpmod_test_2: Read starts parsing response to update with defined readings:
2016.05.24 17:36:56 3: httpmod_test_2: Read response to update didn't match any Reading
2016.05.24 17:36:56 5: httpmod_test_2: HandleSendQueue called, qlen = 0

Gruß
Andreas

[StefanStrobel]

Hallo Andreas,

Deine ReAuthRegex passt nicht.
Der erste Request wird vom Server mit einem schlichten 403 Forbidden beantwortet.
Deine ReAuthRegex sucht aber nach {"success":false}. Das steht da nicht drin. Folglich wird auch kein Login gestartet.

Gruß
    Stefan

[Vize]

Hallo Stefan,

erstmal danke für die Antwort...aber...

wenn ich mal testweise falsche login-Daten im browser eingebe erhalte ich laut burp Mitschnitt die Antwort im angehängten screenshot...

Müsste ich nach deiner Meinung dann als reAuthRegex 403 Forbidden angeben?

Gruß
Andreas