[HowTo] FritzBox - 20 Minuten Zwangs-Logout verhindern

[NAB]

Vorweg:
Ich finde die Übersichtsseite der Fritzbox wirklich praktisch.
Darum hat mich dieser automatische Rausschmiss aus der FritzBox Oberfläche alle 20 Minuten auch gewaltig genervt. Was tut man nun dagegen? Google fand mehrmals die gleiche Frage, aber keine Antwort. Also habe ich selber nach einer Lösung gesucht. Die lange Geschichte der Fehlschläge erspare ich euch (F5 klappt echt nicht), aber mit dieser Lösung hier bin ich jetzt ziemlich zufrieden. Darum veröffentliche ich sie hier.

Was ist das?
Dies ist ein Greasemonkey Script. Greasemonkey ist ein Plugin für Firefox. Greasemonkey ermöglicht es, eigenen JavaScript Code im Kontext der angezeigten Webseite auszuführen und diese so zu manipulieren. Und Firefox ist ein Webbrowser von Mozilla. Getestet ist das ganze bisher auf einer FRITZ!Box 7590 mit FRITZ!OS: 07.12 mit Firefox ESR 68 (unter Linux, aber das sollte keine Rolle spielen).

Was macht das Script?
Es aktualisiert die Übersichtsseite alle 19 Minuten und verhindert dadurch den Timeout, der euch aus der Web-Oberfläche schmeißt.

Wie mache ich das?
Das ist eigentlich ganz einfach. Nachdem man Greasemonkey (bitte über die offizielle Seite von Mozilla) installiert hat, klickt man auf den freundlich grinsenden Affen, klickt auf "New User Script", löscht auf der neu geöffneten Seite die vorgefertigten Zeilen, kopiert dieses Script dort hinein, und klickt auf das kleine "Speichern"-Symbol.

Wie werde ich das wieder los?
Die Holzhammer-Methode: Greasemonkey deinstallieren. Ansonsten installiert sich das Script als "FritzBox KeepAlive", wird als solches angezeigt und kann mit "uninstall" über Greasemonkey wieder entfernt werden.

Funktioniert das so richtig gut?
Nein. Das Script ist dumm, es lädt euch alle 19 Minuten die aktuell angezeigte Seite der FritzBox unter den Fingern weg - auch wenn ihr gerade im Adressbuch was eintragt. Insbesondere bei Firmware-Updates könnte das fatal sein - ich habe es nicht ausprobiert. Zum Glück lässt sich das Script über GreaseMonkey leicht ausschalten, wenn man es nicht braucht.

Nach ca. 24 Stunden werde ich trotzdem rausgeworfen. Ich vermute, dann läuft die SessionID ab. Das reicht mir aber soweit - besser einmal am Tag einloggen als alle 20 Minuten.

Und wenn ihr in die Fritzbox nicht eingeloggt seid, produziert das Script alle 19 Minuten einen JavaScript-Fehler. Den seht ihr aber nicht, und viele Webseiten sind da viel viel schlimmer

Das Script:

// ==UserScript==
// @name        FritzBox KeepAlive
// @author      NAB
// @version     1.2020
// @description Reload FritzBox homepage every 19 minutes
// @match       http://192.168.178.1/*
// @match       https://192.168.178.1/*
// @match       http://fritz.box/*
// @match       https://fritz.box/*
// @grant       unsafeWindow
// ==/UserScript==
// Copyright: GNU GPLv3

var numMinutes = 19;

function reloadmyPage() {
  var loadAddress = 'https://192.168.178.1/?sid=' + unsafeWindow.main.sid + '&lp=overview';
  // console.log(loadAddress) // logs to system console, open with Strg+Shift+j
  document.location.replace(loadAddress)
}

window.setTimeout(reloadmyPage, numMinutes*60*1000);

Eigentlich sollte es so funktionieren, wie es da steht, aber ich erkläre trotzdem noch ein paar Details, damit auch Individualisten Anpassungen vornehmen können.

Die // @match Zeilen:
Damit legt ihr fest, auf welchen Adressen das Script überhaupt aktiv ist. Das sollte so stimmen für die üblichen FritzBox Adressen, aber wer daran rumgebastelt hat, der wird wissen, was er hier eintragen muss.

var numMinutes =
Damit wird festgelegt, nach wievielen Minuten die Seite neu geladen wird.

var loadAddress =
Hier steht die Adresse, die neu geladen wird, um die SessionID am Leben zu halten und einen Rauswurf zu verhindern. Wie kommt man an diese Adresse? Ganz einfach ... klickt links oben auf die drei Querstreifen, haltet die Maus über "Übersicht" und schaut, welchen Link der Browser anzeigt - oder kopiert ihn mit einem Rechtsklick. Im Script steht genau die gleiche Adresse, unterbrochen durch das "unsafeWindow.main.sid", mit dem die aktuelle SessionID (sid) eingefügt wird. Hier könnt ihr auch eine andere Unterseite statt "overview" eintragen, falls euch die mehr interessiert ("Anrufe" wäre: &lp=calls). Und hier muss auch die Adresse geändert werden, falls ihr eine individuelle Konfiguration habt.

Das 's' in https ist übrigens unheimlich wichtig, denn sonst übertragt ihr alle Daten unverschlüsselt und euer Sohn kann mit seinem Laptop euer FritzBox-Passwort mitlesen. Die FritzBox nimmt hier übrigens widerspruchsfrei einen Wechsel von https zu http hin, aber Hauptsache wir haben eine kurze Timeout-Zeit für die Session-ID, um die gefühlte Sicherheit zu erhöhen. Findet das noch jemand sehr lustig?

Das Script ist absichtlich sehr primitiv gehalten, damit es übersichtlich bleibt. Wer etwas sucht, der findet zum Beispiel noch ein Auto-Login-Script, mit dem man die FritzBox endgültig dauerhaft offen halten könnte.

Ist das sicher?
Naja. Grundsätzlich ändert dieses Script keine Einstellungen an eurer FritzBox, sondern steuert deren Weboberfläche über den Browser (ein wenig) fern. Und auch nur über genau den Browser, in dem dieses Script installiert ist. Wenn ihr im Internetcafe oder auf der Arbeit sitzt (und dort das Script läuft), und ihr vergesst euch auszuloggen, dann habt ihr genau die Situation, die AVM mit diesem Timeout wohl verhindern wollte. Der Browser bleibt in die FritzBox eingeloggt. Das Script ist eher als Heim-Lösung gedacht und für Leute, deren PC/Laptop nicht überraschend anderen Familienmitgliedern in die Hände fällt.

Ich mag Firefox nicht?
Tja, und ich mag Chrome nicht so gerne. Und Apple/Microsoft läuft bei mir nicht. Aber für Google Chrome gibt es ein sehr ähnliches Plugin, "Tampermonkey". Die Scripte sollten austauschbar sein, aber ich habe es nicht ausprobiert. Wer probiert es und berichtet?

Welche Alternative gibt es?
Nach meiner Recherche nur:
1) Die FritzBox ohne Passwort betreiben (nicht so schlau, wenn da noch Telefonie und keine Firewall dran hängen)
2) Die "Inhouse" Firmware Versionen sollen einen Timer von 8 Stunden statt 20 Minuten haben. Ich habe es nicht ausprobiert, da mir nicht klar war, welche Vor- und Nachteile ich mir mit dieser Firmware einhandele.

Danke an PeterPawn für den Hinweis, dass es zwei Timer gibt, ich wollte das Ding schon zum Fenster rausschmeißen:

[Gelöst] - Wie kommen die 19 Minuten zustande?

Wenn ich mich bei einer von im meinen Zugriffsbereich befindlichen F!B abmelden will, wird immer eine (sich ändernde) Zahl/Zeit angezeigt, die in keinem ir bekannten Zusammenhang mit der Laufzeit der F!B stehen. Was ist das für eine Zeit? (Hier einen 7390 mit aktueller FW, die zum Zeitpunkt...

www.ip-phone-forum.de

 

[NAB]

Wie ich schon schrieb, mag ich obiges Script gerne, weil es sehr primitiv ist. Es verlässt sich nur auf wenige und leicht prüfbare Eigenschaften der FritzBox und seine Macken sind leicht abschätzbar (Erzwungener Reload alle 19 Minuten).

Trotzdem möchte ich euch folgendes Script nicht vorenthalten, da es vermutlich genau das macht, was sich einige Leute wünschen. Es ist ähnlich dem obigen Script, macht aber einige wichtige Dinge grundlegend anders. Es lädt auch alle 19 Minuten die Übersichtsseite der Fritzbox, allerdings nicht in den Browser, sondern als Text-Objekt in den Speicher. Dadurch löst es einen verdeckten Ladevorgang aus, der den Timer auf der Fritzbox zurücksetzt. Zusätzlich ruft es im Browser eine Funktion des FritzBox Javascript Codes auf, der den Timer im Browser zurücksetzt. Insgesamt entfällt also der erzwungene Reload alle 19 Minuten, dafür gibt es ein paar Abers:

Dieses Script habe ich wenig getestet und es hat einige Eigenschaften, deren Folgen ich schlecht abschätzen kann. Es gaukelt der FritzBox vor, es würde die Übersichtsseite aufgerufen werden - ich habe keine Ahnung, ob es dann zu Fehlern kommen kann, wenn man gerade ganz woanders ist und einen neuen Eintrag ins Adressbuch schreibt oder ein Firmware-Update macht. Dieses Script baut alle 19 Minuten eine Verbindung zur FritzBox auf und bricht sie mitten drin ab ... das ist etwas unfein, scheint aber in tagelangen Tests nicht zu stören. Und dieses Script ist ein Dauerläufer. Das Script oben hat sich alle 19 Minuten selber neu geladen, und dadurch den Speicher aufgeräumt. Dieses Script läuft ewig ... auf lange Sicht (Wochen) könnte es den Speicher füllen - das kann ich nicht beobachten, weil ich auch mit diesem Script alle ca. 24 Stunden herausgeworfen werde. Das Script oben baut wirklich die gesamte Seite neu auf, dieses Script halt nicht. Neue Anrufe und andere Änderungen werden auch bei diesem Script aktuell angezeigt, aber ich weiß nicht, ob das für sämtliche Änderungen gilt. Alles Dinge, die ich nicht so genau ausprobiert habe.

Insgesamt macht das erste Script "normale Dinge", nämlich die Seite neu laden, während das zweite Script Dinge tut, die AVM so vielleicht nicht vorhergesehen hat und die zu unerwarteten Ergebnissen führen könnten, auch wenn's bei mir bisher prima funktioniert. Ihr versteht die Warnung, ja?

Und weil das Script etwas anderes macht, hat es auch einen anderen Namen: "FritzBox HiddenAlive"
Somit installiert es sich auch unter anderem Namen in GreaseMonkey und kann unabhängig vom ersten Script aktiviert und deaktiviert und ausprobiert werden. Ansonsten gilt das im ersten Beitrag Geschriebene zur Installation:

// ==UserScript==
// @name        FritzBox HiddenAlive
// @author      NAB
// @version     1.2020
// @description Keeps you logged in to FritzBox
// @match       http://192.168.178.1/*
// @match       https://192.168.178.1/*
// @match       http://fritz.box/*
// @match       https://fritz.box/*
// @grant       unsafeWindow
// ==/UserScript==
// Copyright: GNU GPLv3

var numMinutes = 19;

var loadAddress = 'https://192.168.178.1/?sid=' + unsafeWindow.main.sid + '&lp=overview';

var myrequest = new XMLHttpRequest();

function refreshTimer() {
  // console.log(loadAddress) // logs to system console, open with Strg+Shift+j
  myrequest.open('GET', loadAddress, true); // to watch request, enable XHR in system console.
  myrequest.send(null);
  // myrequest.abort(); // FritzBox doesn't like that.

  unsafeWindow.main.resetPageTimer(); // resets the timer.
  // unsafeWindow.main.changePage(); // calls resetPageTimer() too.
}

window.setInterval( refreshTimer, numMinutes*60*1000);

Ansonsten gibt es nicht viel zu erläutern. Die "@match"-Zeilen sind gleich geblieben, und auch hier finden sich "numMinutes" und "loadAddress" in gleicher Funktion, und die Adresse muss auch wieder angepasst werden, falls man die Adresse der FritzBox geändert hat.
Die "myrequest"-Zeilen führen den XMLHttpRequest durch, der die Seite "loadAddress" von der Fritzbox abruft und so den Timer in der FritzBox zurücksetzt.
Die Funktion "main.resetPageTimer();" setzt den Timer in der Browser-Oberfläche zurück. (Vorher hatte ich "main.changePage();" ausprobiert, die ruft main.resetPageTimer() auf und tut weitere Dinge, aber main.resetPageTimer() scheint zu reichen.)

Wie ihr seht, verlässt dieses Script sich auf mehr (teils vermutete) Eigenschaften der Fritzbox, die AVM jederzeit ändern könnte. Falls es bei euch nicht wie erwartet funktioniert - erwartet keine Hilfe von mir. Hinweise/Warnungen/Tipps hier im Thread sind natürlich trotzdem gerne gesehen.

Und sonst so?
Ich überlege, wie weit es sinnvoll ist, das (vermutlich erste) Script "intelligenter" zu gestalten. Dazu gehört:
* Eine Prüfung, auf welcher Seite der FritzBox der Anwender sich gerade befindet.
Befindet er sich nicht auf "Übersicht", so könnte das Script geeignet (wie?) reagieren.
* Eine Prüfung, wo der Timer gerade steht. Ist er größer als 1 Minute, so war der Anwender zwischendurch aktiv und ein Reload/Reset ist noch nicht nötig.

Die nötigen Informationen ständen so grob zur Verfügung und ich erwähne sie hier, falls jemand anderes tätig werden möchte:

"main.aktPid" enthält als String die aktuell angezeigte Seite. Die Bezeichner stammen aus "main.pages" und sind nicht immer identisch zu dem Parameter, der als "lp=" übergeben wird ("calls" wird zum Beispiel zu "dialLi", welches die Anruferliste ist, welche sich auch mit "lp=dialLi" aufrufen lässt. "overview" bleibt "overview".).
(main.getLastPid(); gibt übrigens die vorletzte besuchte Seite aus und scheint wiederum dem vorletzten Parameter von lp= zu entsprechen.)

Wie PeterPawn schon festgestellt hat, wird der lokale Timer in avmcontent.js als gPageTimer definiert. An den komme ich aber nicht heran, um ihn auszulesen, da es eine lokale Variable ist. Zumindest nicht, ohne sehr spezifisch in den Code der FritzBox einzugreifen.
Über "document.getElementById("logout_timer").textContent" kommt man aber an die angezeigte Zeit im HTML-Code, allerdings als String, der erst geparsed werden muss. Dem Screenshot von eisbaerin aus dem oben verlinkten Thread nach scheint der immer die Form "XXXm YYs" oder " YYs" zu haben.

 

[NAB]

Und da habe ich so ein schönes Script geschrieben, und dann funktioniert das nicht. Also ... das Script funktioniert sehr gut, aber die FritzBox funktioniert anders als ich mir das dachte.

Ich kann folgendes Verhalten zuverlässig reproduzieren:

00:00 - Login in die Fritzbox, es wird "Übersicht" angezeigt.
        Timer im Browser zeigt 19m59s
00:10 - Timer steht auf 10m00s .
        Klick auf "Telefonie" und auf "Anrufe" und zurück zu "Übersicht".
        Timer steht wieder auf 19m59s
00:20 - Timer steht auf 10m00s.
        Es folgt ein Zwangs-Logout.

Dieses Umherklicken in der Fritzbox-Oberfläche führt also zu einem Reset des Timers im Browser, nicht aber zu einem Reset des Timers in der Fritzbox. Das kann man auch gut in der Browser Console nachverfolgen - es werden zwar .svg und .js Dateien abgerufen, aber es findet kein Abruf mit "sid"-Parameter statt. 20 Minuten nach dem Login antwortet die FritzBox dann auf den POST nach /data.lua mit einem 403 Forbidden und der Browser schließt die Verbindung.

Ebenso führt das Klicken auf den Timer rechts oben zwar zu einem Reset des Timers im Browser, aber nicht zum Reset des Timers in der FritzBox. Ich kann da so oft draufklicken, wie ich will ... wenn ich sonst nichts mache, fliege ich nach 20 Minuten raus (wenn ich auf "Übersicht" bin).

Kann das jemand bestätigen? Ich frage mich langsam, ob an meiner Konfiguration etwas ungewöhnlich ist.

Hier gibt es ebenfalls Hinweise auf Rausschmisse nach deutlich weniger Inaktivität als 20 Minuten:

FritzOS 6.83: automatisches Abmelden aus dem Web-Interface

Hallo, bisher hatte ich eine Fritzbox 7270 mit FritzOS 6.06. Mehr war nicht nötig wg. der installierten Telekom-Infrastruktur. In ein paar Tagen bekomme ich einen Port am hier frisch eingeweihten VDSL-Netz. Also habe ich eine Fritzbox 7412 beschafft und habe jetzt FritzOS 6.83 drauf...

www.ip-phone-forum.de

Auf der anderen Seite:
Ruft man "Internet"->"Online-Monitor" auf, so kann man häufige Abrufe von
hXttps://192.168.178.1/internet/inetstat_monitor.lua?sid=XXX
beobachten, immer abwechselnd mit und ohne &no_sidrenew=1.
Bleibt man auf dieser Seite, wird folglich auch der interne Timer der FritzBox immer wieder zurückgesetzt, der Timer im Browser zählt hingegen runter und schmeißt einen am Ende raus. Setzt man jetzt noch den Timer im Browser rechts oben regelmäßig zurück, bleibt man eingeloggt.

Fazit: es macht für ein Script keinen Sinn, den Timer im Browser auszulesen, da dieser nicht zuverlässig den nächsten Zwangs-Logout ankündigt.

Allerdings funktioniert bei mir folgender kleine Trick, der ganz ohne zusätzliches Plugin und ohne Scripte auskommt:

• Schritt 1: In die FritzBox einloggen.
• Schritt 2: Die Javascript-Konsole eures Browsers öffnen, und zwar in genau dem Fenster/Tab, in dem ihr euch in die Fritzbox eingeloggt habt:
  • ->2a: Firefox: Strg+Shift+K oder
    • Menü -> Web Developer -> Web Console
  • ->2b: Chrome: Strg+Shift+J oder
    • Menü -> Weitere Tools -> Entwickler Tools, Reiter "Console"
• Schritt 3: Bei dem Dreieck in der Konsole, wo man Text eingeben kann, gebt ihr folgende Zeile ein:

window.setInterval(main.resetPageTimer, 18*60*1000);
(Und danach die Eingabetaste drücken)

• Schritt 4: Das Konsolenfenster wieder schließen, da ist rechts ein X. (nicht notwendig)
• Schritt 5: Im FritzBox-Fenster rechts oben den Timer einmal anklicken und so zurücksetzen.
• Schritt 6: Im FritzBox-Menü Internet->Online-Monitor auswählen und auf dieser Seite bleiben.

Solange ihr auf dieser Seite bleibt, werdet ihr nicht rausgeschmissen. Wenn ihr woanders in der FritzBox unterwegs seid, müsst ihr binnen 19 Minuten wieder bei "Online-Monitor" ankommen. (Ganz so schlimm ist es wohl nicht, aber welche anderen Seiten der FritzBox den Timer in der FritzBox am Leben erhalten, müsst ihr selber ausprobieren. "Übersicht" tut es nicht.)

Der Vor- und Nachteil dieses Tricks ist, dass er nicht dauerhaft ist. Schließt ihr das Fenster/Tab oder ladet die Seite neu, so müsst ihr die Zeile neu eingeben. Ihr könnt also auch nichts kaputt machen.

Was macht diese Zeile?
Sie nutzt den Javascript Standard Befehl setIntervall(), der einen gegebenen Befehl in einem gegebenen Zeit-Intervall (hier 18 Minuten) immer wieder ausführt. In diesem Fall den FritzBox-eigenen Befehl resetPageTimer(), der den Timer im Browser zurücksetzt.

Wieso 18? Sonst waren es doch 19?
Mit 18 funktioniert es bei mir besser. Mit 19 Minuten bin ich gelegentlich rausgeflogen.

Weiterführend habe ich dann noch den Trick mit den zwei Tabs auf Lager:

• Schritt 1: Präpariert den ersten Tab wie oben beschrieben.
• Schritt 2: Haltet die Maus über "Übersicht" (es sollte der Link angezeigt werden, auf den "Übersicht" führt, etwas mit &lp=overview), klickt mit der rechten Maustaste drauf und öffnet den Link in einem neuen Tab.
• Schritt 3: Führt im neuen Tab die Schritte 2 bis 5 von oben aus (also gebt die Zeile dort ein).

Das wars. Einen der beiden Tabs lasst ihr auf "Online-Monitor" stehen, mit dem zweiten könnt ihr machen, was ihr wollt.

An dieser Lösung gefällt mir besonders gut, dass nicht künstlich in den Datenverkehr zur FritzBox eingegriffen wird. Lediglich der lokale Timer wird automatisch zurückgesetzt (das könntet ihr auch per Hand machen). Die Bedienung der FritzBox sollte also genau so funktionieren wie vom Hersteller vorgesehen.

Wer aus dieser Zeile ein GreaseMonkey-Script machen möchte, um sie eben nicht immer neu eingeben zu müssen:
Den Anfang könnt ihr euch oben klauen, bis zum // Copyright: GNU GPLv3
Das Script selber besteht nur aus dieser Zeile:

window.setInterval(unsafeWindow.main.resetPageTimer, 18*60*1000);

So, ich denke, das war es erst mal von mir. Diese dritte Lösung läuft bei mir seit Tagen sehr gut und spart die regelmäßigen Reloads der ersten Lösung.

Man könnte das erste Script noch dahingehend erweitern, dass es prüft, ob der Anwender wirklich auf "Übersicht" ist, und nur dann die Seite neu laden - und ihn sonst dem Risiko eines Rausschmisses aussetzen. Oder die Sache noch komplizierter gestalten. Für mich sehe ich dazu keine Notwendigkeit.

 

[PeterPawn]

Mir fehlt halt die Idee, warum bei Dir - solange Du auf der "Übersicht"-Seite bist - nicht auch alle 20 Sekunden (ca.) ein POST-Request (als XHR und mit dem Ziel "data.lua") ausgelöst werden sollte.

Der erfolgt zwar tatsächlich mit dem Parameter "no_sidrenew", aber m.W. kommt es bei dem gar nicht darauf an, welchen Wert er am Ende hat - seine reine Existenz reicht aus, damit der Timer für die Session (in der Benutzerverwaltung des "ctlmgr") nicht zurückgesetzt wird. Die unterschiedlichen Aufrufe (mal mit "no_sidrenew=1" und mal nur mit "no_sidrenew=") hängen sowohl von der Firmware-Version als auch von der "Quelle" eines solchen Requests ab und bewirken am Ende doch dasselbe ... die Session wird durch keine der beiden Varianten verlängert/erneuert.

Wird der Parameter per Lua schon dem generierten HTML-Text als Link irgendwo hinzugefügt, kommt meist die "1" zum Einsatz, weil dafür die Funktion "addUrlParam" bzw. "buildUrlParam" in Lua verwendet wird und die wird i.d.R. mit "1" für den Wert aufgerufen. Stammt der Aufruf aber aus dem JS-Code im Browser (z.B. aus einem Aufruf von "http.request" mit einer Option "sidRenew", die nicht den Wert "true" hat oder wohl auch aus einem Aufruf ohne diese Option), wird auch schon mal ein KV-Paar ohne Wert (also mit '') erzeugt, was dann dazu führt, daß im POST-Request nach dem Gleichheitszeichen nichts mehr steht.

Aber egal, welcher Wert dort hinter dem "no_sidrenew" steht ... taucht dieser Name im Request auf, wird die Session nicht verlängert. Ob und wo man den jetzt versucht herauszufiltern, ist zwar "Geschmackssache", aber die Funktion "http.buildParams" (in "avmcore.js" zu finden) könnte (auch wenn sie nicht als Methode "exportiert" ist über das "http"-Objekt) ein guter Ansatzpunkt sein. Überspringt man hier das "data.push" für name == "no_sidrenew" in der "for"-Schleife über die "name"-Auflistung, setzt JEDER Request die Session zurück ... vielleicht auch nicht ganz das, was man wirklich will, aber dann braucht man tatsächlich nur noch das Logout per JS unterbinden und die Session in der Box dauert ewig - jedenfalls solange irgendein Request (egal, ob GET oder POST) regelmäßig per XHR abgesetzt wird - wobei eben nicht alle Seiten im GUI regelmäßig nach neuen (JSON-)Daten suchen (aber "overview" bzw. "home/home.lua", wie die Seite hinter dem "overview" wirklich heißt, dann schon).

Je nachdem, wieviel Aufwand man jetzt beim Ändern des JS-Codes von AVM betreiben will (die "avmcore.js" ist ja wenigstens eine eigene Datei und kann damit per "beforescriptexecute"-Event in GM abgefangen und ersetzt werden), kann man das Entfernen des POST-Parameters ja auch auf bestimmte Requests beschränken ... man muß halt nur beachten, daß die alle an "data.lua" gehen und erst das dann (üblicherweise anhand des "lp"-Parameters) als eine Art "Sprungverteiler" dient und die "richtige Seite" aufruft. Durch die "data.lua" wirkt das praktisch nur als SPA (single page application) in den Ansätzen bzw. (zumindest auf die XHRs bezogen) aus der Sicht des Browsers.

Das nimmt einem zwar auch noch nicht das Zurücksetzen des lokalen Timers im Browser ab, aber wenn man den Mechanismus schon mal hat, kann man da ja auch gleich eingreifen (der Timer-Teil steht aber in der "avmcontent.js"). Wobei es vermutlich sogar wieder simpler ist, man setzt einfach rechtzeitig einen eigenen XHR ab und damit dann den Timer in der Box zurück. Die Auswertung des "no_sidrenew"-Parameters erfolgt (afaik and iirc) direkt in der "/usr/www/cgi-bin/luacgi" ... also dem Binary, was für die Interpretation von Lua-Files zuständig ist unter dem Webserver des "ctlmgr". Der Request sollte also schon für eine Lua-Seite sein und nicht etwa für "system_status" oder "juis_boxinfo.xml" ... aber auch da gibt es eben genug "Nullseiten", die außer einem - mehr oder weniger leeren - JS-Array keine Daten weiter zurückliefern und auch ansonsten am Status der Box nicht groß herumschrauben.

Allerdings wird so eine Lösung dann immer vom JS-Code von AVM abhängen ... da kann man sie eigentlich auch gleich in der Box bzw. in der installierten Firmware ändern - die Abhängigkeit von AVM bleibt dieselbe, nur hat man das dann auch in einem Browser, der kein eigenes GreaseMonkey/TamperMonkey mit passendem Skript benutzt und man kann da noch ein paar nette "Zusatzfunktionen" einbauen, z.B. eine Checkbox für das Ein-/Ausschalten dieser "ewigen Anmeldung", damit das dann vielleicht doch nicht für JEDE Session (mit einem Browser mit JS-Capabilities, direkte Aufrufe per "wget" oder "curl" sind davon ohnehin nicht betroffen) angewandt wird, denn letztlich ist so eine lange Session eben auch ein Sicherheitsrisiko (je nachdem, welche Rechte der verwendete User am Ende hat).

 

[NAB]

Danke für die Antwort,

Mir fehlt halt die Idee, warum bei Dir - solange Du auf der "Übersicht"-Seite bist - nicht auch alle 20 Sekunden (ca.) ein POST-Request (als XHR und mit dem Ziel "data.lua") ausgelöst werden sollte.

Der erfolgt zwar tatsächlich mit dem Parameter "no_sidrenew", [...]

Da habe ich mich unklar ausgedrückt, bzw. gar nicht ausgedrückt. Auf "Übersicht" erfolgt bei mir in der Tat alle ca. 20 Sekunden ein POST auf
hXtps://192.168.178.1/data.lua
aber genau so, wie er dort steht, ohne jegliche Parameter. (ausgelöst von avmcontent.js, sagt Chrome)
Das "data.lua" habe ich mir eben auch noch mal genauer angeguckt (mithilfe von Chrome), dort ist die sid enthalten, aber ich finde keinen Parameter, der "no_sidrenew" ähnlich wäre.

Auf "Internet-> Online-Monitor" erfolgt ein GET auf
hXtps://192.168.178.1/internet/inetstat_monitor.lua?sid=abc&myXhr=1&action=get_graphic&useajax=1&xhr=1&t1583455444675=nocache
und auf:
hXtps://192.168.178.1/internet/inetstat_monitor.lua?sid=abc&no_sidrenew=1&myXhr=1&action=get_table&useajax=1&xhr=1&t1583455698071=nocache
(ausgelöst von avmold.js)
ca. im 5 Sekunden Takt.

Ohne mir jetzt den AVM-Code genauer angeguckt zu haben, schließe ich daraus, dass ein "lebenserhaltender" Request den Parameter "sid" enthalten muss und den Parameter "no_sidrenew" nicht enthalten darf.

Wenn ich dich recht verstehe, willst du darauf hinaus, den Parameter "no_sidrenew" generell rauszufiltern. Das könnte man (Achtung, völlig unausgegorene Idee!) vielleicht dreist machen, indem man die vorhandenen .js-Dateien einfach per Suchen&Ersetzen durchgeht und sie danach "bereinigt" installiert. Die Methode könnte auch relativ stabil gegen Code-Veränderungen sein.

Nur scheint "Übersicht" bei mir anders zu funktionieren. Da tauchen in den Requests weder "sid" noch "no_sidrenew" auf.

Das nimmt einem zwar auch noch nicht das Zurücksetzen des lokalen Timers im Browser ab, aber wenn man den Mechanismus schon mal hat, kann man da ja auch gleich eingreifen (der Timer-Teil steht aber in der "avmcontent.js"). Wobei es vermutlich sogar wieder simpler ist, man setzt einfach rechtzeitig einen eigenen XHR ab und damit dann den Timer in der Box zurück. Die Auswertung des "no_sidrenew"-Parameters erfolgt [...]

Das macht mein zweites Script (im zweiten Beitrag), das macht einen XHR GET auf "&lp=overwiew", mit sid, funktioniert auch prima, aber ich kenne mich mit der Software auf der FritzBox nicht gut genug aus um beurteilen zu können, ob die immer stateless ist, oder ob man sie mit Requests in unerwarteter Reihenfolge aus dem Tritt bringen kann (und ob das immer so bleiben wird, ich wollte hier ja gerne einigermaßen zukunftstaugliche Lösungen anbieten). Ich verstehe aber nicht, wie bzw. warum du hier auf "no_sidrenew" kommst ... wenn man die Anfragen selber schneidert, kann man den doch einfach weglassen?

denn letztlich ist so eine lange Session eben auch ein Sicherheitsrisiko (je nachdem, welche Rechte der verwendete User am Ende hat

Genau deswegen halte ich von Firmware-Modifikationen hier auch nicht so viel (mal abgesehen davon, dass der Aufwand für mich sicherlich viel größer wäre als für dich ). Bei meinen Ansätzen muss der Anwender halt den Browser modifizieren statt der Firmware, und er muss gezielt den Browser modifizieren, der die Session auch dauerhaft offen halten soll. Die "Checkbox" zum Ein- / Ausschalten ist auch gleich mit dabei. Das "dauerhaft" beschränkt sich bei mir aber auf 24 Stunden. Wenn der FritzBox eine neue IP zugeteilt wird, scheint auch die sid zu erlöschen.

Ansonsten gibt's diese Firmware-Modifikation schon, die ist nämlich eingebaut. Um den blöden Timer loszuwerden, muss man nur die Passwort-Abfrage auschalten. Ehhh ... wie war das mit der Sicherheit? Ich halte das für ein echtes Unsicherheitsfeature, was AVM da implementiert hat. Und ich finde es ziemlich lustig, dass die das anscheinend ernst meinen. Aber ich habe auch einen komischen Humor

 

[PeterPawn]

aber genau so, wie er dort steht, ohne jegliche Parameter.

Ich denke mal, da guckst Du falsch (ist halt ein POST und kein GET, wo Parameter im Querystring stehen - hier ist es ein:

Content-Type: application/x-www-form-urlencoded

und die Daten stehen im Body des Requests) oder der Chrome-Debugger zeigt das ggf. auch einfach falsch an.

Da mir der aber nicht auf die Platte kommt, kann ich das nur im Firefox-Debugger zeigen:


Ansonsten haben beide Möglichkeiten der Integration/Modifikation ihre Stärken und Schwächen ... beim nachträglichen Modifizieren per GM oder TM steht man spätestens dann auch auf dem Schlauch, wenn für dasselbe Gerät bzw. dieselbe IP-Adresse (wenn man die User-Skripts an die Adresse binden will, was man dann bei n Boxen eben auch n-mal machen müßte) zwei unterschiedliche Modifikationen erforderlich sind, weil AVM in der Firmware geändert hat und man zwischen zwei Versionen (z.B. einer Labor- und einer Release-Version) wechselt.

Während dann bei einer Änderung direkt in der Firmware die jeweils passende Modifikation erfolgen könnte und es dem Browser egal sein kann, welche FRITZ!OS-Version jetzt auf dem Gerät läuft, von dem er gerade die Seite lädt, muß bei unterschiedlichen Änderungen auf der Browser-Seite diese Unterscheidung im Browser erfolgen (und feiner als bis zur IP-Adresse kann das ein Add-On dann auch nicht auflösen) und daß bei der Benutzung mehrerer Geräte (mit unterschiedlichen Browsern) zum "Bedienen" der FRITZ!Box jede dieser Anpassungen dann auch auf derselben Anzahl von Geräten erfolgen muß, versteht sich ebenfalls von selbst.

Hier ist also die Frage, welche Art und Weise der Modifikation die bessere ist, deutlich davon abhängig, wie die konkreten Rahmenbedingungen aussehen - jemand mit 10 Boxen (mit unterschiedlichen FRITZ!OS-Versionen) und 4 PCs/Tablet/was auch immer, wird sicherlich eher zur "zentralen Modifikation" in der FRITZ!Box-Firmware greifen und eher selten zur dezentralen Lösung mit jedem einzelnen Browser (da sind vermutlich die 10 Boxen schon deutlich übertrieben, obwohl es sicherlich genug Leute gibt, die auch "im Ehrenamt" eine entsprechende Anzahl fremder Boxen mitbetreuen).

Am Ende ist es auch ein Frage des Aufwands, den man investieren will ... sowohl in die erstmalige Implementierung als dann auch in die spätere "Wartung" und Anpassung an Änderungen bei AVM. Wobei eben JS-Code-Änderungen bei beiden Ansätzen zu entsprechendem Aufwand führen - das läßt sich aber kaum verhindern.

 

[NAB]

Ich denke mal, da guckst Du falsch

Ahhhh! Da hast du sowas von Recht! Danke für den Wink mit dem Zaunpfahl. Ich benutze eigentlich auch Firefox, aber hab's mir dann mal mit Chrome angeguckt, weil der auf den ersten Blick mehr und übersichtlichere Informationen anzubieten schien, und bin dann konfus zwischen beiden umhergewechselt.

Ich rudere dann mal zurück und behaupte das Gegenteil: auch "Übersicht" schickt Requests mit "no_sidrenew=", und soweit ich das bisher sehe, nur solche.

Ich habe noch etwas durch den Javascript-Code gestöbert, und eigentlich sieht mir die Arbeitsanweisung ganz einfach aus: Tausche in jeder .js-Datei den String "options.sidRenew" durch "true" aus (Vorkommnisse bei mir je einmal in avmcore.js und avmold.js), und es dürfte kein Request mit "no_sidrenew" mehr rausgehen, und der restliche Betrieb sollte auch nicht gestört sein.

Aber dann bin ich gleich auf das nächste Problem gestoßen:

Element: beforescriptexecute event - Web APIs | MDN

The beforescriptexecute event is fired when a script is about to be executed. Cancelling the event prevents the script from executing.

developer.mozilla.org

Mit beforescriptexecute kann ich nur eine Lösung basteln, die ausschließlich auf Firefox läuft. Ich schau noch mal, ob ich andere Ansätze finde, eventuell eine ganz andere Plugin-Klasse. Eine Art Filtering-Proxy scheint mir hier das Richtige zu sein.

... beim nachträglichen Modifizieren per GM oder TM steht man spätestens dann auch auf dem Schlauch, wenn für dasselbe Gerät bzw. dieselbe IP-Adresse (wenn man die User-Skripts an die Adresse binden will, was man dann bei n Boxen eben auch n-mal machen müßte) zwei unterschiedliche Modifikationen erforderlich sind, weil AVM in der Firmware geändert hat und man zwischen zwei Versionen (z.B. einer Labor- und einer Release-Version) wechselt.

Ich verstehe voll und ganz, dass du das Übel am liebsten an der Wurzel, also an der Firmware angehen möchtest. Aber die müssen erstellt werden, gepflegt werden, und aufgespielt werden. Ich vermute, das wird den durchschnittlichen Heimanwender noch mehr überfordern als ein Plugin zu installieren und ein Script zu kopieren.

Die größte Macke von Firmware-Modifikationen scheint mir zu sein, dass du aktiv werden *musst*, wann immer AVM eine neue Version herausgibt (vorausgesetzt, du willst die Geräte mit aktueller Firmware betreiben). Bei den Scripten besteht zumindest die Möglichkeit, dass sie auch mit der nächsten Firmware-Version funktionieren (das wäre eigentlich auch mein Anspruch, aber mir fehlt das Testbett dazu).

Auf dem Schlauch stände ich bei den von dir genannten Beispielen noch lange nicht. Dass sich zwei Boxen gleichzeitig die gleiche IP teilen, ist unmöglich, und wenn man die Box oder die Firmware austauscht, wäre der Austausch des Scriptes wohl die leichtere Übung. Natürlich wäre es bei größeren Installationen wünschenswert, das Script aufzubohren, so dass es auf unterschiedliche Konfigurationen reagiert. Die nötigen Informationen kann ich so grob zusammensuchen:

main.menuBox.baseURI verrät einem die aktuelle Adresse der FritzBox.
document.getElementById('avmLogo').textContent; enthält den Gerätenamen.
Und in main.serviceUrl finde ich etwas unleserlich die Firmware-Version. Der Gerätename scheint in der Adresse auch noch irgendwie codiert zu sein.

(Und gerade entdeckt: In main.menu findet sich eine Zuordnung von &lp-Parametern und den deutschen Überschriften der GUI.)

Ich kann hier aber schlecht die eierlegende Wollmilchsau präsentieren, dazu fehlt mir die Motivation, das Testbett und eine Vorstellung davon, was die Leute mit z.B. 10 Fritzboxen überhaupt machen.

 

[gabrierz]

Servus,

hast du jetzt eine Lösung gefunden?
Denn
Code:

window.setInterval(unsafeWindow.main.resetPageTimer, 18*60*1000);
funktioniert bei mir nicht, ich werde einfach weiter ausgeloggt.

 

[Limer]

Danke @NAB für das Script bzw. die schon investierte Arbeit.
Mich hat dieser verdammte AutoLogout heute auch mal wieder genervt und bevor ich anfing selber ein Script zu schreiben habe ich glücklicherweise deines gefunden.

... und habe direkt einen Verbesserungsvorschlag.
Ersetze die Statisch definierte IPv4 Adresse in loadAddress durch den dynamisch ausgelesenen Host (inkl. Port) der tatsächlich gerade geöffneten Seite.
Ich bin mir sicher das das geht, gerade aber zu faul es selber zu machen.

Dies ist somit auch eine Notiz/Erinnerung an mich selbst daran bei Gelegenheit mal zu basteln.

Weitere Ideen/Vorschläge:

1. auf github weiter machen (Revisionsvergleiche sind eine schöne Sache und das userscript kann sich von da automatisch Updates holen).
2. dynamisch erkennen ob die geladene Seite tatsächlich von einer FB stammt.
   Grund: Ich habe gleichzieitg zugriff auf mehere FBs in mehreren Netzen (VPNs) und würde gerne solche @matches nehmen.
   1. http*://192.168.*.*/*
   2. http*://fritz[a-zA-Z0-9]+/* (keine TLD, nur ein einsamer hostname)
   3. https://*.myfritz.net/*
   4. http*://fritz.box/*
3. Nicht zu einer fest definierten ansicht zurück-laden sondern tatsächlich die aktuelle Ansicht neu laden (mich interessiert z.B. Internet -> DSL-Informationen -> Statistik).

 

[kdt]

Falls es jemanden interessiert. Ich habe für mich ein kleines Programm gebastelt, welches alle 10 Sekunden überprüft, ob noch ein Login zur FB besteht und ggf. ein Relogin macht. Voraussetzung ist das Vorhandensein einer aktuellen MSEdgeDriver.exe (MS EDGE Chromium) oder einer aktuellen ChromDriver.exe (Chrome Browser).

Syntax:  keepFB.exe /PW=Password [/FB=url][/C] [/help]
url=Fritz!Box address (default=fritz.box)
password=Fritz!Box local Password (needed)
option /C = Use ChromeDriver.exe instead of MSEdgeDriver.exe

 

[bugmenot4711]

Hier geht es gut mit einer Mischung aus Tampermonkey und main.resetPageTimer:

// ==UserScript==
// @name        FritzBox no auto logout
// @author      Jaleks
// @version     2020-07-20
// @description Reset FritzBox logout timer every second
// @match       http://fritz.box/*
// @match       https://fritz.box/*
// @grant       unsafeWindow
// ==/UserScript==

(function() {
    'use strict';

    function resetTimer(){
        var timer = document.getElementById('logout_timer')
        if(timer){
           // console.log("found logout timer");
           try{
               unsafeWindow.main.resetPageTimer();
           }
           catch (e){
               // console.log("could not reset: "+ e);
           }
        }
        else{
           // console.log("no logout timer");
        }
    }
    setInterval(resetTimer, 1000);

})();

das setzte sekündlich den Logout timer zurück, ohne Neuladen HTTP-Requests o.ä.

 

[♝ 卩ℝỖＯĐᑎⓄＦ 卂нⓐ]

Unnötiges Vollzitat von darüber gemäß Boardregeln entfernt by stoney

GEIL GEIL GEIL

Wenn jedes Problem so eine einfache Lösung hätte, wäre die Welt viel besser :*

Vielen vielen Dank!

EDIT: Leider zu früh gefreut. Ab und an ist man dann doch abgemeldet, obwohl oben rechts weiterhin der Timer konstant bei "20m 0s" steht. Der Unterschied ist, dass das höhnische "Erfolgreich abgemeldet" jetzt nicht auftaucht, wenn man was anklickt. Hat jemand eine Idee?

 

[mystacor]

Würde nicht das hier reichen:

time=setInterval(function(){
document.getElementById("logout_timer").click()
},60000);

 

[fda89]

Ich hatte vor längerem den Timeout im Quelltext der Webseiten erhöht. Dies wurde auch im Browser auch korrekt angezeigt.
Die Session wurde aber trotzdem genau nach 20 Minuten beendet. Vermutlich ist da noch ein Timer im Webserver/ctlmgr

 

[mystacor]

@fda89: hast recht, tut leider nicht

 

[PeterPawn]

Vermutlich ist da noch ein Timer im Webserver/ctlmgr

Das ist sogar ganz gewiß so (siehe #4 - außerdem blieben sonst ja "orphaned SIDs" unbegrenzt gültig, wenn man einfach den Browser schließt und der das der Box nicht "mitteilen" kann) - das kann man nach einem "msgsend ctlmgr sessions" auch in der Datei "/var/tmp/sessions.txt" in der Box sehen und zwar in der Spalte "valid", wo die verbleibenden Sekunden gezählt werden bis zum Timeout der Session. Das wird dann bei einem passenden Request (wieder sei auf #4 verwiesen) auch wieder auf den Standardwert von 1200 Sekunden zurückgesetzt.

EDIT:
Das wäre auch mal eine zusätzliche Anzeige in Freetz[-NG] wert - das ist nämlich eine Info, die man ansonsten nur über die Support-Datei erhält und wo eine Shell-Session auf der Box (je nachdem, wie man sich dafür angemeldet hat) dann schon wieder in Richtung eines Kohärenzproblems geht, weil man mit der eigenen Anmeldung für eine solche Shell-Session das System bereits wieder verändert.

Da wäre eine Anzeige, welche Benutzer gerade an der FRITZ!Box angemeldet sind, wie lange die Sessions noch laufen, von wo der Zugriff erfolgt und mit welchem Account, schon eine nützliche Information - wenn man sich dafür interessiert. Aber innerhalb der "Log-Seite" bei Freetz[-NG], wo ansonsten auch alle möglichen und unmöglichen Protokolle angezeigt werden, könnte das durchaus nützlich sein - besonders dann, wenn da mehrere Benutzer und möglichst auch noch ein paar Apps existieren.

 

[fda89]

Naja, bei AVM schaue ich lieber nach ob es wirklich so ist...
Ich muss mir zuerst mal ein Image mit Supportdaten flashen

 

[Limer]

Hier geht es gut mit einer Mischung aus Tampermonkey und main.resetPageTimer:

// ==UserScript==
------- SNIP ------------

das setzte sekündlich den Logout timer zurück, ohne Neuladen HTTP-Requests o.ä.

Ich habe das leicht veränderte Script (danke dafür) im aktuellen FF 68.12.0esr an meiner FB7490 mal getestet.

Spoiler: UserScript

// ==UserScript==
// @name        FritzBox no auto logout
// @author      Jaleks (& Limer)
// @version     2020-09-11
// @description Reset FritzBox logout timer every five minutes
// @include     /^https?:\/\/(www\.)?(my)?fritz[a-z0-9]*(\.box|\.nas)?(\:[0-9]+)?\//
// @include     /^https?:\/\/192\.168\.[0-9]+\.1(\:[0-9]+)?\//
// @grant       unsafeWindow
// ==/UserScript==

(function() {
    'use strict';
    var counter = 0;
    var intervID;
    var intervTime = 5; // in minutes

    function resetTimer(){
        var timer = document.getElementById('logout_timer')
        if(timer){
            counter++;
            console.log("found logout timer (#" + counter + " x " + intervTime + "min.)");
            try{
                unsafeWindow.main.resetPageTimer();
            }
            catch (e){
                console.log("could not reset: "+ e);
            }
        }
        else{
            console.log("no logout timer after hit #" + counter);
            clearInterval(intervID);
        }
    }
    intervID = setInterval(resetTimer, (intervTime * 60 * 1000));
})();

Modifikationen:

• @Match -> @include um mit RegEx mehr Namen und beliebige Ports zu erfassen.
• Wurde kein logout timer gefunden so wird setInterval getötet.
• Intervalldauer von 1s auf 5m erhöht (warum 1s @bugmenot4711 ?).
• Zähle Ausführungen der Schleife zum Debuggen.

Dabei habe ich folgendes beobachtet (FF Konsole mit Strg+Shift+K):

1. Auf der Seite "Internet -> DSL-Information" im Tab "DSL" scheint es zu funktionieren.
   Ich war nach über 20 Minuten noch immer angemeldet und die Seite holt alle paar Sekunden (~5) folgende URL per "XHR GET"
   https://fritzNAME:PORT/internet/dsl_stats_tab.lua?update=mainDiv&sid=BLA&useajax=1&xhr=1&t1599843952916=nocache
2. Auf der Seite "Heimnetz -> Netzwerk" funktioniert es nicht.
   Hier wird aber auch nur alle paar Sekunden ein "XHR POST" an https://fritzNAME:PORT/data.lua geschickt (auch mit ähnlichen Parametern wie unter 1.).
3. Auf der NAS Seite der FB HTTPS://www.fritz.nas/ scheint es keinen automatischen logout Timer zu geben (ich sehe keinen, habe aber noch nicht getestet ob man trotzdem nach 20 Minuten noch angemeldet ist).
   Evtl. ist es möglich einfach auf der NAS Seite eingeloggt zu bleiben und nur bei Bedarf zur eigentlichen FB Seite zu wechseln (setzt natürlich voraus das der angemeldete User Zugang zum NAS und der Konfiguration hat).
4. Auf der Seite "System -> Ereignisse" wird nichts aktiv von der Seite selber angefragt. Nur wenn man auf aktualisieren klickt (auf der Seite, nicht im Browser) gibt's einen "XHR POST" an https://fritzli:43351/data.lua.

NACHTRAG #1:
bzgl. 1. - man scheint doch nicht auf ewig eingeloggt zu bleiben... :-( aber man bleibt es trotzdem länger als 20m.

NACHTRAG #2 (es geht doch!):
bzgl. 1. - Wenn das Browser Tab mit der Seite die ganze Zeit aktiv / im Vordergrund und das Fenster nicht minimiert ist so bleibt man für Stunden (>7h) eingeloggt.
Ich schließe daraus das entweder FF JScript ein paar Energiesparmaßnahmen aufzwingt oder ein Fritzbox Script das bemerkt und kein automatisches refresh mehr macht (was dann auch den logout_timer resetter ins leere laufen lässt).

 

[Olivier Jacot-Descombes]

Ich habe eine funktionierende Lösung und bin einen ganz anderen Weg gegangen. Statt das Ausloggen zu verhindern und mich mit den FritzBox Timern herumzuschlagen, detektiert mein Skript den «Anmelden» Knopf und klickt ihn, um erneut einzuloggen.

Dabei geht das Skript davon aus, dass der Browser (in meinem Fall Firefox) das Passwort automatisch ausfüllt. Damit das passieren kann, wartet das Skript 5 Sekunden und klickt erst dann den Knopf.

Vorteile:

• Das Passwort muss nicht im Skript abgelegt werden.
• Das Skript wird nur dann aktiv, wenn die Login-Seite erscheint und funkt nicht rein, wenn man in der FritzBox etwas anderes tut.

Nachteil:

• Man landet immer wieder auf der Hauptseite.

// ==UserScript==
// @name        FritzBox ReLogin
// @author      Olivier Jacot-Descombes
// @version     2020.12.19
// @description Makes a automatic login when FritzBox logged out
// @match       https://fritz.box/*
// @match       https://192.168.178.1/*
// @grant       unsafeWindow
// ==/UserScript==

var numSeconds = 5;

function relogin() {
  var submitButton = document.getElementById('submitLoginBtn');
  if (submitButton) {
    submitButton.click();
  }
}

window.setInterval(relogin, numSeconds*1000);

 

[kone9]

Danke Olivier Jacot-Descombes
Mit etwas Nachhilfe funktioniert Dein Greasemonkey-Skript super.
1. Da Firefox offensichtlich Probleme mit Anmeldungen ohne Benutzer hat, habe ich erst (System, FritzBox-Benutzer) einen angelegt und dann auf Anmeldung mit FRITZ!Box-Benutzernamen und Kennwort umgestellt. Dieser wird dann auf der Anmeldeseite vorausgewählt, mein FF brauchte ihn dann nicht mehr!?
2. Da Firefox auch Probleme mit Anmeldungen ohne Zertifikat hat (selbst wenn man sich auf einer http Seite anmelden möchte, verhindert die Warnung den weiteren Lauf des Skripts), bin ich so vorgegangen: https://avm.de/service/fritzbox/fri...at-herunterladen-und-am-Computer-importieren/
Danach klappte die Anmeldung auf https://fritz.box/ immer automatisch.
Da das Skript erwartet, dass FireFox das Passwort sofort ein gibt, ist es sinnvoll erst eine andere Seite auf zu rufen, welche auch ein Passwort erfordert, damit das Hauptpasswort bereits abgefragt wurde.
PS: Ich lande direkt wieder da wo ich vor dem Rauswurf war.