neuer Login für 3rd-Party Software ab OS 07.24/07.25

frank_m24

IPPF-Urgestein
Mitglied seit
20 Aug 2005
Beiträge
17,664
Punkte für Reaktionen
14
Punkte
38
Moin zusammen,

bekanntermaßen hat AVM den Login zu Fritzboxen ab OS 07.24 aufgebohrt, nun wird standardmäßig ein Nutzername benötigt. Davon betroffen sind auch 3rd-Party Apps, die eine Session-ID wollen:

Ich hab gestern mal Quick and Dirty die Munin Scripte für Fritzboxen (https://github.com/Tafkas/fritzbox-munin) angepasst, so dass sie wieder Werte liefern (aktuell noch nicht wirklich vorzeigbar, sondern hardcoded im helper-script). Nun wird aber jeder Zugriff im Log der Fritzbox brav mitgeschrieben. Kann man das irgendwie verhindern? Der Hinweise, dass sich Nutzer fritz1234 538 Mal eingeloggt hat, ist nur so semi-hilfreich ...

Gibt es pfiffigere Möglichkeiten, an die Werte zu kommen? In den TR-064/UPnP Werten hab ich nicht alles gefunden.

Grüße
Frank
 

Chronosone

Neuer User
Mitglied seit
22 Dez 2007
Beiträge
72
Punkte für Reaktionen
0
Punkte
6
Für den Fall das die Frage noch aktuell ist.

So richtig brauchbar ist diese Info erst ab dem 1001 Login des Users. ;)

Was die Werte angeht so ist die Frage welche du genau meinst.

Der Gebrauch der TR064-Schnittstelle wird ja nicht im Log mitgeschrieben.

Braucht man abseits der Doku Werte so gibt es ja z.B. noch die query.lua.
Diese "API" ist jedoch nicht dokumentiert und kann sich jederzeit wieder ändern.

Ich würde die Session einmal beziehen und dann über die Laufzeit der App aufrecht halten solange sie benötigt wird.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,764
Punkte für Reaktionen
1,260
Punkte
113
über die Laufzeit der App aufrecht halten solange sie benötigt wird
Das Problem ist halt, daß Munin-Plugins eigentlich "stateless" sein sollten ... es gibt also keine "einfache" Möglichkeit, eine SID von einer Plugin-Instanz (eines Master-Nodes) an die nächste zu übergeben. Allerdings ist dieses "Ansinnen" jetzt auch nicht sooo ungewöhnlich, daß es in Munin nicht doch auch dafür eine Möglichkeit gäbe: https://guide.munin-monitoring.org/...vanced-topics.html#storing-the-plugin-s-state

Dazu müßte man sich nur die fritzbox_helper.py anpassen: https://github.com/Tafkas/fritzbox-munin/blob/master/fritzbox_helper.py und in get_login_state() (https://github.com/Tafkas/fritzbox-...c71b80c58a7f527b88a116/fritzbox_helper.py#L71) die in der letzten "Session" gesicherte SID einlesen (wenn das nicht geht, ist es auch nicht weiter schlimm, dann braucht man halt ein neues Login), damit man diese mit in den Request an die FRITZ!Box einbauen kann (einfach als Parameter sid). Angesichts der letzten Änderung vor wenigen Tagen, wo zwar die neuen Notwendigkeiten (Username) und Möglichkeiten (PBKDF2) eingebaut wurden, ist das für den dortigen Autoren offenbar kein Problem, das es zu lösen gilt.

Ist diese SID weiterhin gültig, kriegt man dieselben Daten zurück, die es auch nach einem erfolgreichen Login gäbe ... man kann dann also das erneute Login in get_login_id() (https://github.com/Tafkas/fritzbox-...c71b80c58a7f527b88a116/fritzbox_helper.py#L53) einfach auslassen (diese Zeile wäre die nächste, die dann auszuführen ist: https://github.com/Tafkas/fritzbox-...c71b80c58a7f527b88a116/fritzbox_helper.py#L66), muß sich dort aber dann (am besten in den else-Zweig für die ungültige SID) noch das Sichern der SID für ein erfolgreiches Login einbauen, damit das Auslesen beim nächsten Run dann auch etwas finden kann.

Das ist im Prinzip das "Aufrechterhalten" - nur ist das wegen der (sicheren) Speicherung pro Plugin-Instanz (es kann ja auch mehrere Nodes mit diesem Plugin geben, die unterschiedliche Boxen verwenden) in Munin nicht ganz so einfach (aber auch nicht wirklich kompliziert).

Etwas "komplexer" ist es aber schon, man sollte also zumindest Python beherrschen, denn am besten fügt man gleich dem Tupel, das von get_login_state() zurückgegeben wird, noch die SID (oder Nullen, falls es die Session nicht mehr gibt) hinzu - das XML-Parsen hat man da ja ohnehin schon und man kann den Wert direkt aus der XML-Response übernehmen, ohne sich einen Kopf machen zu müssen, was da drin steht. Ist die "alte" SID noch brauchbar, gibt der Aufruf sie unverändert zurück, ansonsten setzt sie das FRITZ!OS in der Antwort selbst auf die Nullen, mit denen eine ungültige SID angezeigt wird.

Dann muß man sie in get_login_id() nicht (erneut) auslesen aus dem MUNIN_STATEFILE und kann in Zeile 53 gleich testen, ob die SID aus Nullen besteht. Ist das schon dort nicht der Fall, kann alles das, was bisher in den Zeilen 53 bis 65 steht, per Condition übergangen werden - das dürfte die wenigsten Änderungen ggü. dem Original erfordern. Ob man dann das Sichern der (alten) SID erneut(!) ausführt oder das nur dann macht, wenn es auch tatsächlich eine "neue" SID gab, ist wieder Geschmackssache und eher von anderen Überlegungen (Frequenz von Änderungen, Speicherort und Anzahl der Zugriffe (Flash), etc.) abhängig.

Auf alle Fälle wird man auf diesem Weg die ständig neuen Meldungen zum Login im Ereignisprotokoll der FRITZ!Box wieder los. Wenn AVM nichts Neues eingebaut hat in X_AVM-DE_CreateUrlSID() (die TR-064-Dokumentation wurde erst im Januar 2021 wieder mal geändert: https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceconfigSCPD.pdf, aber wohl nur das SupportData-Handling ergänzt), KÖNNTE man sich aber wohl auch immer noch eine SID per TR-064 besorgen (ob das dann eine "Anmeldung einer App" (anstelle "eines Benutzers") bewirkt, die auch per TR-064 protokolliert wird, hängt m.W. davon ab, ob dafür ein Konto aus der app-Sektion der ar7.cfg benutzt wird) und mit dieser dann trotzdem auf die GUI-Dateien zugreifen - da gab es bisher keine "echte Unterscheidung", solange die Rechte des Kontos, was für den TR-064-Aufruf zum Erlangen dieser SID verwendet wurde, auch die für einen Zugriff auf die gwünschte URL erforderlichen Rechte einschließen.

Das könnte dann das Speichern der SID obsolet machen (obwohl das auch nicht unsicherer ist, als die Speicherung von Benutzernamen und Kennwort) ... braucht aber immer noch mehr Änderungen - obendrein kann AVM ja irgendwann auch mal die eigene "Drohung" wahr machen und zwischen Sessions für das GUI und Sessions für TR-064-Requests richtig unterscheiden (wenn das immer noch wie beschrieben klappen sollte, ich habe es länger nicht mehr getestet/protokolliert, mit 07.0x ging es wohl noch, wenn ich meinen Aufzeichnungen trauen kann). Obendrein braucht es dann zwei Schnittstellen, wenn nicht alle Daten ebenso per TR-064 ausgelesen werden können - die sind auch noch unabhängig voneinander konfigurierbar (zumindest kann man TR-064 deaktivieren, während das GUI (auf der LAN-Seite) immer geht).
 
  • Like
Reaktionen: frank_m24

frank_m24

IPPF-Urgestein
Mitglied seit
20 Aug 2005
Beiträge
17,664
Punkte für Reaktionen
14
Punkte
38
@PeterPawn: Danke! Vielleicht schaue ich mir das morgen mal näher an.

Bin zwar kein Python Experte, aber das beschriebene werde ich mal ausprobieren.
 

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via