die nennt die nötige Vorgehensweise "web scraping"
So einen Schwachsinn kann auch nur eine KI verzapfen, zumindest im Kontext des FRITZ!OS, von dem (genauer: dessen GUI-Funktionen) sie offenbar keinen Schimmer hat.
Erstens ist es gar nicht (mehr) erforderlich, irgendwelche HTTP-(GET-)Requests (abseits der Anmeldung zur Erzeugung einer gültigen Session-ID) an die Box zu senden, um HTML-Inhalte (egal ob statisch oder dynamisch, wobei das ganze GUI ja mittlerweile eher eine "single page application" ist und damit "scraping" (zumindest "statisches") ohnehin Blödsinn ist, denn die Inhalte im DOM des Browsers werden alle dynamisch erzeugt) zu erhalten - man kann genauso gut direkt die Requests absetzen, die die anzuzeigenden Daten (als Response im JSON-Format) erst einsammeln, die dann ins DOM eingebastelt werden.
Zweitens hat AVM seit einiger Zeit auch ein JSON-basiertes (Aktions-)Interface ins FRITZ!OS eingebaut (
https://www.ip-phone-forum.de/threads/fritzbox-7590-ax-steuern-via-skript.324286/post-2635595) und wenn im GUI der "Neu verbinden"-Button gedrückt wird, werden da nacheinander zwei (PUT-)Requests an die Box gesendet (dafür braucht es einen passenden Header:
AUTHORIZATION: AVM-SID <sid> im Request, die
sid für die Sitzung (mit einem Konto mit administrativen Rechten) muß man ggf. zuvor erzeugen - wie das geht, steht bei AVM:
https://fritz.support/resources/HTTP_Session-ID_DE.pdf), der erste mit dem (JSON-)Kommando
JSON:
{
"cmd_disconnect": "1"
}
und danach (logischerweise) ein weiterer mit
... ob der zweite tatsächlich erforderlich ist, wenn andere Clients im LAN Daten anfordern aus dem Internet, sei mal dahingestellt.
Man kann also auch einfach diesen (oder diese beiden) PUT-Request(s) auslösen (wie geschrieben, muß dafür eine SID erzeugt werden und vermutlich sollte der
Content-Type-Header auch den Payload als
application/json ausweisen, sicher ist sicher) und die Box sollte sich genauso verhalten (vielleicht muß man noch ein kurzes Delay zwischen beiden Aufrufen einbauen, wobei das bei AVM auch nicht der Fall ist:
Javascript:
reconnect = async() => {
const LX = a96i;
await a96g[LX(407)](baseUrl, {
'cmd_disconnect': '1'
}),
await a96g[LX(407)](baseUrl, {
'cmd_connect': '1'
});
},
), als wenn da jemand den oben erwähnten Button gedrückt hätte.
In PowerShell sähe das dann in etwa so aus (nur die Trennung wird gezeigt und die SID war auch aus dem Browser kopiert):
C-ähnlich:
PS C:\Users\XXX> $hdr = @{ Authorization = "AVM-SID 5883faae68b23511" }
PS C:\Users\XXX> Invoke-WebRequest -Uri "http://192.168.65.1/api/v0/generic/connections" -Method PUT -Body '{"cmd_disconnect":"1"}' -ContentType "application/json" -Headers $hdr
StatusCode : 200
StatusDescription : OK
Content : {}
RawContent : HTTP/1.1 200 OK
Connection: Keep-Alive
Transfer-Encoding: chunked
Pragma: no-cache
Keep-Alive: timeout=60, max=300
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Security-P...
Forms : {}
Headers : {[Connection, Keep-Alive], [Transfer-Encoding, chunked], [Pragma, no-cache], [Keep-Alive, timeout=60, max=300]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : System.__ComObject
RawContentLength : 2
PS C:\Users\XXX>
Alles keine "rocket science" und dafür einen Browser "fernsteuern" zu wollen (inkl. der Tatsache, daß der ja dann auch sein JavaScript ausführen muß, ansonsten bleibt das DOM nur der Rumpf), ist (1) nicht erforderlich, wie gezeigt, und (2) eine wirklich blöde Idee in meinen Augen.