[gelöst] HTTPMOD - Website hat login-Verfahren geändert

[Vize]

Ahoi,

nachdem das Device nun so wunderbar (wieder) funktioniert, habe ich noch eine spezielle Zusatzfrage...

Die Readings werden mit extractAllJSON erzeugt.
Darunter befindet sich ein reading zum "Zustand", also ob der Akku gerade beladen, entladen usw. wird.

Auf der Webseite und in burp bzw. den browser-Entwicklertools werden die Daten korrekt dargestellt.
Beispiel siehe screenshots.

Unter buf im HTTPMOD-Device - und somit im reading - steht aber dann das.

Code Auswählen Erweitern

"readable_state":"?com.senecies.meinsenec.senec.model.SteuereinheitState.PV_UND_ENTLADEN?"

Hat jemand eine Idee, wie man es hinbekommen kann, dass dieses reading "lesbar" erzeugt wird, also als "PV und Entladen" usw. ?

Was mir noch aufgefallen ist: Rufe ich die Webseite im browser unter linux Ubuntu auf, steht im browser der Status ebenfalls in der "Langversion" wie im reading des HTTPMOD-Devices...
Da FHEM bei mir auf einem RasPi mit Raspbian läuft, könnte es vielleicht damit zusammenhängen?

Im Moment behelfe ich mir mit readingOMap, um das reading entsprechend umzubiegen. Vielleicht gibt es ja eine elegantere Lösung?

Danke schonmal für jegliche Hilfe!

Gruß
Andreas

[StefanStrobel]

Für mich klingt das so als ob der Server abhängig vom User-Agent eine andere Antwort liefert.
Das sollte sich mit Burp nachvollziehen lassen. Hängt vermutlich auch nur an einem Header ...

Gruss
    Stefan

[Vize]

OK, werde ich mal testen.

Danke für den Tipp!

Gruß
Andreas

[Vize]

Also, wenn ich den User-Agent

Code Auswählen Erweitern

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
als getHeader angebe, ändert sich nichts.
Als requestHeader bringt auch nichts...

Burp unter Ubuntu habe ich mir aber noch nicht angeschaut...

Gruß
Andreas

[StefanStrobel]

Burp müsste nicht auf einem anderen System laufen.
Wenn Du mit einem Browser unter Windows eine korrekte Antwort bekommst, diesen Request über Burp als Proxy schickst und aufzeichnest und dann die Aufzeichnung in Burp im Repeater nochmals absendest, muss die gleiche korrekte Antwort kommen.
Damit hier nichts schief läuft einfach den aufgezeichneten Request per Rechtsklick an den Repeater senden. Dann muss der absolut gleiche Request auch die gleiche Antwort liefern. Bei dem ersten Request über Burp als Proxy kommt der Request ja auch von Burp...

Dann würde ich den Request nochmal Header für Header mit Deiner vereinfachten Konfiguration vergleichen.
Irgendwo muss ein Unterscheid sein.

Du könntest auch den Browser auf einem Ubuntu-System über den Burp-Proxy auf Deinem Windows-System schicken und das aufzeichnen und mit dem funktionierenden Request vergleichen.

Gruss
   Stefan

[Vize]

Hallo Stefan!

Wenn Du mit einem Browser unter Windows eine korrekte Antwort bekommst, diesen Request über Burp als Proxy schickst und aufzeichnest und dann die Aufzeichnung in Burp im Repeater nochmals absendest, muss die gleiche korrekte Antwort kommen.

Jepp, das hatte ich auch schon getestet, passt auch.

Dann würde ich den Request nochmal Header für Header mit Deiner vereinfachten Konfiguration vergleichen.
Irgendwo muss ein Unterscheid sein.

Ich hatte auch schon versucht, alle Header aus dem browser-Request mitzuschicken. War bisher leider auch erfolglos...werde ich mir aber nochmal vornehmen.
Nur zum Verständnis, die Header (der Seite mit den Daten) muss ich doch mit getHeaderXX mitgeben, oder?

Du könntest auch den Browser auf einem Ubuntu-System über den Burp-Proxy auf Deinem Windows-System schicken und das aufzeichnen und mit dem funktionierenden Request vergleichen.

Diesen Satz verstehe ich leider nicht...was genau meinst du damit, und wie macht man das?

Gruß
Andreas

[StefanStrobel]

Hallo Andreas,

Wenn Dein Browser unter Ubuntu andere Daten liefert als der unter Windows, dann müsste man die Unterschiede in den Requests einfach finden können wenn beides über Burp aufgezeichnet wird.
Da die Burp-Suite als Netzwerk-Proxy arbeitet, muss der Browser nicht auf dem gleichen Sytem laufen wie der Proxy. du kannst auch dem Browser auf einer Ubuntu-Maschine sagen, dass er als Proxy die Adresse und den Port verwenden soll, auf dem Burp auf einer andern System lauscht.
Einfach in den Proxy-Settings des Browsers eintragen ...

Gruß
    Stefan

[Vize]

Sorry, Stefan, jetzt versteh ich nur noch Bahnhof...

In der burp-Suite stelle ich doch generell den Proxy auf 127.0.0.1:8080...oder was meinst du mir "Adresse und Port verwenden soll, auf dem Burp auf einem anderen System lauscht"?
Wie soll ich da was in den Proxy-Einstellungen des browsers eintragen?

Ich raff's einfach nicht... 

Komme mit burp unter Ubuntu mit Firefox auch nicht weiter. Stelle ich im Firefox den Proxy 127.0.0.1:8080 gemäß burp ein, warnt Firefox beim Aufruf der https-Seite vor einem nicht bekannten Zertifikat, und dass Firefox keine Ausnahme hinzufügen kann...ich kann die Seite dann nicht aufrufen.
Manuell kann ich das Zertifikat von burp auch nicht im Firefox einpflegen...
Kann es also bisher nicht unter Ubuntu mit Firefox nachstellen.

Gruß
Andreas

[StefanStrobel]

Hallo Andreas,

statt 127.0.0.1 kannst Du in der Burp Suite unter Proxy - Options auch angeben, dass der Proxy auf allen Adressen des Systems antworten soll.
Dann kannst Du die LAN-Adresse des Systems mit Burp als Proxy auf anderen Systemen angeben.

Gruss
    Stefan

[Vize]

Hallo Stefan,

vielleicht dämmert es mir so langsam, worauf du hinaus willst...sicher bin ich aber nicht...

Ich starte Windows und Ubuntu aus einem Multi-Boot-System heraus vom gleichen PC.
Die LAN-Adresse des Systems ist also immer die gleiche, weil fest für den PC vergeben.

Falls du das meintest...

Gruß
Andreas

[StefanStrobel]

Ok, auf einem Multiboot-System bringt Dich das nicht weiter.

Gruss
    Stefan

[Helms-je]

Bei mir funktioniert es auch wieder! Spitzenklasse, ganz vielen Dank für die Arbeit und sorry, dass ich keine Zeit hatte, mit zu helfen!

Hallo,

seit dem 30.06 geht das login so nicht mehr. Gibt es eine Lösung?

mfg
Jens

[parabacus]

Hallo!

Ich hab im Keller auch einen SENEC-Speicher stehen und schau mir fast täglich die Daten auf der SENEC-Seite an.

Ich bin vor einigen Tagen soz. per Zufall auf FHEM gestossen, da ich unserer Wärmepumpe ein Interface verpassen wollte. Nachdem ich das erfolgreich geschafft habe, entstehen natürlich weitere Wünsche. 
Nach Bemühen der Forums-Suche mit Schlagwort "SENEC", kam dieser Beitrag als einziges Ergebnis. Mit Bedauern habe ich den letzten Eintrag gelesen...
Nichts desto Trotz würde mich dennoch interessieren, wie die Einbindung in FHEM dann überhaupt funktioniert. Aus den Codeteilen in den einzelnen Beiträgen konnte ich leider nicht schlau werden. Ich muss auch noch zugeben, dass ich in Sachen FHEM noch recht "grün" bin, von Programmierung aber schon etwas Ahnung habe - allerdings in C, bisher nur auf embedded Systemen und das ist auch schon einige Jahre her.
Vielleicht mag jemand ein paar erklärende Worte dazu schreiben - wäre sehr nett!

Ciao
Tom

PS: ..und Klasse wär's, wenn's wieder funktionieren würde.

[Tiger84]

Hallo zusammen,

vielen Dank für die guten Info's hier im Thread. Ich habe heute meinen Speicher von Senec bekommen. Ich konnte das Device von Vizw leider noch nicht testen, da ich den online Zugang noch nicht habe.

Ich stelle mir aber die Frage, warum es über die Daten über die Website https://mein-senec.de einbinden soll, wenn ich doch genauso gut per LAN und IP auf den Speicher zugreifen kann? Hier kann ich durch den Aufruf der lokalen IP ohne Benutzername usw alle Daten sehen.

Oder ist das nur eine versteckte Weiterleitung? Wäre ja einfacher lokal zu bleiben, oder irre ich mich hier?

[parabacus]

Inzwischen bin ich schon hinsichtlich FHEM um einiges schlauer geworden und hab auch schon vieles probiert und teilweise integriert.
Jetzt bin ich hier wieder angekommen, da ich noch immer Interesse habe, u.a. meinen Speicher-Status mit anzuzeigen und ggf. damit auch später mal was zu steuern.
Nach einiges Versuchen es so zu machen, wie Vize (Andreas), bin ich aber noch nicht ans Ziel gekommen. Entweder ich mach was falsch oder es geht noch immer nicht.

@Tiger84: Hast du dich vielleicht an der Möglichkeit den Akku lokal im LAN einzubinden versucht?