ü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).
