und wie man sieht Erfolgt der UPNP Login bei der Abfrage zur 2FA per digest,
Hier verstehe ich nicht, worauf Du hinauswillst.
Das oben Gezeigte hat ja mit UPnP nichts zu tun ... selbst wenn man (wie AVM es früher auch mal getan hat) die internen TR-064-Schnittstellen in diesen Kontext einordnen will.
Was ich in dem Protokoll sehe, ist (a) ein vergeblicher Zugriff auf "webcm", der mit "404" endet, weil die Datei nur noch in den Inhouse-Versionen überhaupt existiert.
Danach kommt (b) ein Aufruf der "login_sid.lua" ohne gültige SID - die Box antwortet korrekt mit "200" und passender XML-Struktur, wie es bei AVM beschrieben ist für das GUI-Login (auch wenn das lange "deprecated" ist, hat sich AVM noch nicht zum Entfernen dieser "login_sid.lua" entschlossen, die m.W. aber vom AVM-Code selbst gar nicht (mehr) verwendet wird):
https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/Session-ID_deutsch_06Feb18.pdf - ja, AVM hat diese Beschreibung sogar noch einmal verbessert vor einem Vierteljahr. Man kann also wohl davon ausgehen, daß man sie als alternativen Weg des Zugangs verwenden kann - allerdings gibt es über das GUI eben keinen Zugriff auf 2FA-geschützte Funktionen, wenn 2FA auch aktiv ist ... dann
muß man halt über TR-064 gehen.
In der XML-Struktur ist dann die Challenge der Box enthalten und deshalb kann der dritte Versuch (c) erfolgreich abgewickelt werden - am HTTP-Fehlercode kann man aber (b) und (c) ohnehin nicht unterscheiden, nur am Inhalt der XML-Daten ... besteht die dort enthaltene SID nur aus Nullen, ist sie nicht gültig (und man kann über diese "login_sid.lua" auch prüfen, ob eine bereits vorhandene SID noch gültig oder ob sie bereits abgelaufen ist).
Die letzte Abfrage (d) ist dann genauso "Standardkost", wie jede andere Seite in der Box - im Gegensatz zu den anderen Aufrufen unterhalb von "cgi-bin", bei denen praktisch immer HTTP-POST-Requests erwartet werden, reagiert "system_status" auch auf GET-Requests (das Shell-Skript dahinter kann sich ja jeder in der Firmware ansehen, im Gegensatz zu den anderen Dateien, die "echte" Binaries sind).
Hier hat also nach meiner Ansicht die Java-Klasse "Authenticator" gar nichts zu tun ... zumindest nicht im HTTP-Kontext.
===========================================================
Ich hatte nur bei einem Mitschnitt im LAN gesehen, daß Du jetzt nach diesen von Dir oben gezeigten Requests noch POST-Requests an den Control-Point "<fritzbox>:
49000/upnp/control/x_auth" sendest.
Das ist eben aus zwei Gründen (zumindest potentiell) falsch
in meinen Augen ... erstens beschreibt AVM selbst dort nur TLS-gesicherte Zugriffe (
https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/AVM_TR-064_first_steps.pdf - u.a. Beispiel in Punkt 10.5) für alles, was über das "GetSecurityPort" hinausgeht und zweitens kann man das damit (zumindest theoretisch) auch von AVM aus jederzeit auf dieses "nur mit TLS erlaubt" umstellen.
Zeitweise wiesen die Ergebnisse im weiter vorne von mir verlinkten Thread schon darauf hin, auch wenn die am Ende wohl doch einfach falsch waren, weil die eigentliche Ursache mit dem fehlenden "Host"-Header erst später genauer untersucht wurde und die gilt sowohl für TLS (da auch noch als SNI) als auch ohne.
Auf diesen ersten Request (ohne Authorization im Header) kommt von der Box auch nur die Antwort:
Code:
HTTP/1.1 401 Unauthorized
Connection: keep-alive
Content-Length: 170
Content-Type: text/html
Pragma: no-cache
Server: Webserver
WWW-Authenticate: Digest realm="HTTPS Access",nonce="BC82150EAE885222",algorithm=MD5,qop="auth"
<HTML><HEAD><TITLE>401 Unauthorized (ERR_NONE)</TITLE></HEAD><BODY><H1>401 Unauthorized</H1><BR>ERR_NONE<HR><B>Webserver</B> Thu, 10 May 2018 10:28:35 GMT</BODY></HTML>
Hier "tarnt" sich also die Box noch einigermaßen ("Webserver" als eigene Identität) und fordert zur Authentifizierung auf.
Das erfolgt aber dann (sicherlich automatisch seitens der "Authenticator"-Klasse in Java) mit ganz schwerem Geschütz (siehe "Authorization"-Header):
Code:
POST /upnp/control/x_auth HTTP/1.1
USER-AGENT: AVM UPnP/1.0 Client 1.0
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: urn:dslforum-org:service:X_AVM-DE_Auth:1#GetInfo
Connection: close
Cache-Control: no-cache
Pragma: no-cache
Host: 192.168.XXX.1:49000
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Length: 271
Authorization: Digest username="", realm="HTTPS Access", nonce="BC82150EAE885222", nc=00000001, uri="/upnp/control/x_auth", response="86683b49f9ea06afb0b5df8612xxxxxx", algorithm=MD5, cnonce="GCBEACMFJIEIIMPLABCEPCOPGNKJCPHPGPBLKBLL", qop=auth
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body><u:GetInfo xmlns:u="urn:dslforum-org:service:X_AVM-DE_Auth:1">
</u:GetInfo>
</s:Body>
</s:Envelope>
---------------------------------------------------------------
HTTP/1.1 401 Unauthorized
Connection: keep-alive
Content-Length: 170
Content-Type: text/html
Pragma: no-cache
Server: Webserver
WWW-Authenticate: Digest realm="HTTPS Access",nonce="5818BB6825E0B4A8",algorithm=MD5,qop="auth"
<HTML><HEAD><TITLE>401 Unauthorized (ERR_NONE)</TITLE></HEAD><BODY><H1>401 Unauthorized</H1><BR>ERR_NONE<HR><B>Webserver</B> Thu, 10 May 2018 10:28:35 GMT</BODY></HTML>
Das hier gleich mit "nc" (nonce-count), "uri" (domain) und einer "cnonce" (client nonce) zu machen, ist zwar RFC-konform (zur neuen Version in RFC 2617), aber es gibt auch dort (siehe Punkt 3.2.2 im RFC) eigentlich noch Möglichkeiten zur Rückwärtskompatibilität mit der alten Version in RFC 2069. Ich hatte halt aufgrund nachfolgender Beobachtungen die Befürchtung (die sich als falsch erwiesen hat), daß die FRITZ!Box hier nur die einfachere Form versteht.
Fakt ist nämlich erst einmal, daß sich der AVM-Server auch hier relativ unbeeindruckt zeigt vom Versuch der Authentifizierung ... da hätte es genauso gut sein können, daß er die Authentifizierung gar nicht versteht (je nach verwendeten Parametern aus diesem Header ergibt sich ja ein anderer Ausgangswert beim Zusammensetzen der Zeichenketten für das Hashen mit MD5) und daher nichts damit anfangen kann - das war zumindest eine halbwegs plausible Vermutung, warum da bei mir auf Port 49000 nur Fehlversuche zu sehen waren.
Denn die Java-Klasse versuchte es dann gleich noch einmal, diesmal mit einem zusätzlichen "username" im Header, der aber hier noch leer ist, weil er gar nicht abgefragt wurde (ich starte den Editor ohne Voreinstellungen und er fragt (Offenbar von Dir inzwischen geändert? Oder war das schon immer so?) erst einmal nur die Adresse und das Kennwort - sequentiell - ab) und damit kann die Box dann auch noch nichts anfangen (obwohl das Login ins GUI per "login_sid.lua" aufgrund einer Besonderheit ("remote_access_user = xx;" in der "ar7.cfg", noch aus den "ganz alten Zeiten") zuvor auch ohne Benutzernamen geklappt hatte):
Code:
[...]
Authorization: Digest username="", realm="HTTPS Access", nonce="5818BB6825E0B4A8", nc=00000001, uri="/upnp/control/x_auth", response="6752bc0445edcf92c31ad7dbba29c855", algorithm=MD5, cnonce="JJGJLLNAIOCNMFLAKABEDECNNJIPAJPGAOAGJFLI", qop=auth
[...]
HTTP/1.1 401 Unauthorized
[...]
WWW-Authenticate: Digest realm="HTTPS Access",nonce="0B47A532B2FB906A",algorithm=MD5,qop="auth"
Der Server ändert also lediglich stoisch seine "nonce" ... mehr erreicht dieser Zugriff nicht. Der FBEditor versucht(e) das aber nun in aller Gelassenheit noch ein paar Mal, solange bis der AVM-Server die Geduld verliert und anstelle von "401" mit "500" antwortet:
Code:
POST /upnp/control/x_auth HTTP/1.1
USER-AGENT: AVM UPnP/1.0 Client 1.0
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: urn:dslforum-org:service:X_AVM-DE_Auth:1#GetInfo
Connection: close
Cache-Control: no-cache
Pragma: no-cache
Host: 192.168.XXX.1:49000
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Length: 271
Authorization: Digest username="", realm="HTTPS Access", nonce="AC724FE964895B0F", nc=00000001, uri="/upnp/control/x_auth", response="8dea3f6859a1ae2294b83c0110xxxxxx", algorithm=MD5, cnonce="FJKHEDOGDKFLCIOKPGLPNNCEEEOJBCIHGAGECGFL", qop=auth
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body><u:GetInfo xmlns:u="urn:dslforum-org:service:X_AVM-DE_Auth:1">
</u:GetInfo>
</s:Body>
</s:Envelope>
-------------------------------------------------------
HTTP/1.1 500 Internal Server Error
DATE: Thu, 10 May 2018 10:28:35 GMT
SERVER: FB7490 UPnP/1.0 AVM FRITZ!Box 7490 113.06.92
CONNECTION: close
CONTENT-LENGTH: 429
CONTENT-TYPE: text/xml; charset="utf-8"
<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:dslforum-org:control-1-0">
<errorCode>401</errorCode>
<errorDescription>invalid action</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>
Putzig ist hier einerseits, daß der AVM-Server dermaßen die Nerven verliert, daß er auf seine "Tarnung" als "Webserver" verzichtet, die Maske fallen läßt und voller Ärger kundtut, daß man so mit "FB7490 UPnP/1.0 AVM FRITZ!Box 7490 113.06.92" nicht umspringen darf.
Andererseits ist das Ergebnis dann (nur rein durch den Start des Editors ohne Voreinstellungen und die Eingabe von Adresse und Kennwort - ohne Benutzer, weil der nicht abgefragt wurde) auch das folgende Bild im Event-Log der Box:
(Ich habe hier mal ausnahmsweise das Vollbild eingefügt, weil die Vorschau doch sehr winzig und z.B. bei Touch-Bedienung kaum gezielt zu erreichen ist.)
===========================================================
Ein wenig liegt das Problem am FBEditor (der den Benutzernamen nicht abfragt) und ein wenig auch am FRITZ!OS in der von mir verwendeten Version und Konfiguration. Denn wenn der Benutzername korrekt ist, funktioniert es (unter 06.92) auch tatsächlich, den Status der 2FA über eine unverschlüsselte Verbindung per TR-064 abzufragen:
Code:
POST /upnp/control/x_auth HTTP/1.1
USER-AGENT: AVM UPnP/1.0 Client 1.0
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: urn:dslforum-org:service:X_AVM-DE_Auth:1#GetInfo
Connection: close
Cache-Control: no-cache
Pragma: no-cache
Host: 192.168.XXX.1:49000
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Length: 271
Authorization: Digest username="xxx", realm="HTTPS Access", nonce="DA2304CF8101652A", nc=00000001, uri="/upnp/control/x_auth", response="e171162211b593f540c207c07fxxxxxx", algorithm=MD5, cnonce="BKPNKHDPODHHBHMPJPJFDNJOGFAFNDKGKJFEGNKC", qop=auth
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body><u:GetInfo xmlns:u="urn:dslforum-org:service:X_AVM-DE_Auth:1">
</u:GetInfo>
</s:Body>
</s:Envelope>
------------------------------------------------------
HTTP/1.1 200 OK
DATE: Thu, 10 May 2018 11:24:46 GMT
SERVER: FB7490 UPnP/1.0 AVM FRITZ!Box 7490 113.06.92
CONNECTION: close
CONTENT-LENGTH: 298
CONTENT-TYPE: text/xml; charset="utf-8"
EXT:
<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:GetInfoResponse xmlns:u="urn:dslforum-org:service:X_AVM-DE_Auth:1">
<NewEnabled>0</NewEnabled>
</u:GetInfoResponse>
</s:Body>
</s:Envelope>
Die "volle" Digest-Authentifizierung stört die Box also offenbar nicht, das versteht der AVM-Server dann doch.
Aber trotzdem sollte man diese Zugriffe nur über TLS abwickeln, wenn es denn möglich ist - schon damit die übertragenen Daten geschützt sind. Das sind sie nämlich ansonsten nicht wirklich (über "firmwarecfg"), weil im Request das Export-Kennwort im Klartext nachzulesen ist und in der Response dann die damit verschlüsselte Einstellungsdatei. Das läßt sich dann ganz simpel von jedem "Lauscher" wieder entschlüsseln:
https://www.ip-phone-forum.de/threa...verschlüsselung-für-die-einstellungen.295101/
===========================================================
Jedenfalls wird bei der 7490 (wenn ich alles zuvor von Hand schon eingestellt hatte, auch den Benutzernamen) dann beim erneuten Aufruf auch ordentlich erkannt, daß die 2FA aktiv ist und das Einlesen daran scheitert. Bei der 6490 (Retail, 06.83) gibt das hingegen nach der TR-064-Abfrage neue Späne ... der FBEditor (die vorne verlinkte Version) verzieht sich in eine Warteschleife (keine CPU-Belastung) und wartet da auf irgendetwas Unbekanntes - das GUI reagiert jedenfalls gar nicht und auch der Versuch, den Editor zu schließen, endet dann nur mit dem Abbruch der zu diesem Zeitpunkt noch offenen TCP-Verbindung zum Port 80 der Box (die wird ja mehrfach genutzt, ist HTTP/1.1). Ansonsten wartet der Editor munter weiter und ich muß den Prozess abschießen. Das aber wieder nur dann, wenn die Zugangsdaten bereits zuvor hinterlegt wurden ... trage ich die erst "frisch" ein, erkennt er sogar bei der 6490 die aktivierte 2FA richtig.
Hingegen kommt - wenn man zwar die IP-Adresse einer existierenden FRITZ!Box angibt, aber kein Kennwort und keinen Benutzernamen - auch schon mal die Fehlernachricht, daß die Box nicht gefunden würde ... obwohl deutlich im LAN-Mitschnitt zu sehen ist, daß da Kommunikation stattfindet.
Das meinte ich weiter oben mit einer "Check-Liste", anhand derer der Benutzer wirklich sehen kann, welcher Schritt fehlschlägt ... denn diese Fehlernachricht bei fehlendem Kennwort und fehlendem Benutzernamen verwirrt natürlich einigermaßen, denn die Box wurde ja in Wahrheit doch gefunden.
===========================================================
Ich würde also folgende Änderungen empfehlen (ohne in den Quelltext zu schauen, was davon schon vorgesehen ist und vielleicht nur nicht richtig funktioniert):
(A) Prüfen der SID, die von "login_sid.lua" zurückkommt - die sollte eben nicht nur aus Nullen bestehen (ansonsten stimmen die Login-Daten nicht) und auch den tatsächlichen Rechten des Nutzers (unter "Admin" in der XML-Struktur) sollte man noch einen Blick gönnen ... selbst wenn der (korrekt angemeldete) Benutzer da keine Rechte hat:
Code:
<?xml version="1.0" encoding="utf-8"?><SessionInfo><SID>4e5c8266a1e54b84</SID><Challenge>8272a06a</Challenge><BlockTime>0</BlockTime><Rights><Name>NAS</Name><Access>2</Access></Rights></SessionInfo>
, versucht der Editor es trotzdem erst mal. Auch das Berücksichtigen von "BlockTime" wäre nicht sooo verkehrt ... selbst wenn Benutzername und Kennwort korrekt sind, wird es eben keine gültige Anmeldung geben, solange der Wert bei "BlockTime" größer als 0 ist. Der kann ja durchaus auch von irgendjemand anderem in die Höhe getrieben worden sein bzw. werden - wenn man hier trotzdem den eingegebenen Benutzernamen und das Kennwort in Zweifel zieht dank falscher Fehlermeldungen, verwirrt das nur noch zusätzlich.
(B) Am besten wäre es sogar, wenn man erst einmal
nur über TR-064 versucht, die Box zu erreichen ... dann erkennt man auch an der ersten Antwort bereits, ob TR-064 nun ein- oder ausgeschaltet ist (hier ist es generell ausgeschaltet als Beispiel):
Code:
POST /upnp/control/deviceinfo HTTP/1.1
SOAPACTION: urn:dslforum-org:service:DeviceInfo:1#GetSecurityPort
Content-Type: text/xml; charset="utf-8"
Host: 192.168.XXX.1:49000
Content-Length: 262
Expect: 100-continue
Connection: Keep-Alive
-----------------------------------------------------------------
HTTP/1.1 100 continue
-----------------------------------------------------------------
<?xml version="1.0"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:GetSecurityPort xmlns:u="urn:dslforum-org:service:DeviceInfo:1"></u:GetSecurityPort></s:Body></s:Envelope>
-----------------------------------------------------------------
HTTP/1.1 500 Internal Server Error
DATE: Thu, 10 May 2018 16:33:55 GMT
SERVER: FB7490 UPnP/1.0 AVM FRITZ!Box 7490 113.06.92
CONNECTION: keep-alive
CONTENT-LENGTH: 433
CONTENT-TYPE: text/xml; charset="utf-8"
<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
<errorCode>401</errorCode>
<errorDescription>Invalid Action</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>
(C) Begrenzen der Anzahl der Fehlversuche
bei irgendeiner Anmeldung - leider stellt AVM keine
klare Information bereit (zumindest kenne ich kein derartiges Interface, was man auch ohne vorherige Anmeldung abfragen könnte und "LANConfigSecurity" hilft hier auch nicht richtig weiter), ob der eingestellte Anmelde-Modus nun einen Benutzernamen und ein Kennwort braucht oder nur ein Kennwort. Aber man kann sich hier mit einem Kniff helfen und aus dem HTML-Inhalt der ersten Seite beim direkten Aufruf des GUI die notwendigen Daten extrahieren (mal mit einer Linux-Shell als Beispiel):
Code:
vidar:~ # wget -qO- http://192.168.XXX.1 | sed -n -e "s|^var data = \(.*\);\$|\1|p" | jq -C "{ WAN: .fromInternet },{ Users: .activeUsers }"
{
"WAN": false
}
{
"Users": [
[],
[],
[],
[]
]
}
Aus diesen JSON-Variablen interessieren eigentlich nur die Werte für "activeUsers" und "fromInternet" (oben von mir "umbenannt" in "Users" und "WAN") ... beim Aufruf aus dem LAN (fromInternet: false) und leerem Array bei "activeUsers" (wobei "leer" nicht ganz stimmt, weil AVM da zumindest auch die Anzahl der vorhandenen Benutzerkonten verrät durch die
Anzahl der leeren Einträge) steht die Box auf "Anmeldung nur mit dem Kennwort", beim Zugriff aus dem Internet ist immer ein Benutzername erforderlich (der betreffende Benutzer braucht dann auch noch die passenden Rechte für einen solchen Zugriff) und da bei der Umschaltung auf "Anmeldung mit Benutzername und Kennwort" mindestens ein Benutzer angelegt sein muß, ist das Array aus dem LAN heraus dann nicht leer (eigentlich ein Security-Problem, weil das "Erraten" eines gültigen Benutzernamens wegfällt - aber das macht es (komme ich gleich drauf) unter bestimmten Umständen ohnehin).
Bei "Keine Anmeldung erforderlich" (der dritten möglichen Einstellung) liefert die "login_sid.lua" auch dann eine gültige SID, wenn man keine Zugangsdaten angegeben hat ... das kriegt man aber auch über TR-064 mit "LANConfigSecurity::X_AVM-DE_GetAnonymousLogin()" heraus - gleichzeitig wüßte man mit einer solchen TR-064-Abfrage auch sofort, ob das TR-064 nun ein- oder ausgeschaltet ist, wenn man nicht zuvor (wie oben angeführt) mit "GetSecurityPort()" schon Schiffbruch erlitten hat.
Zumindest die Fehlversuche, die sich aus fehlendem Benutzernamen i.V.m. einem Kennwort ergeben, kann man damit verhindern ... auch ein Beitrag zur "Hygiene" im Event-Log der Box, wo die (erfolgreiche) Anmeldung ja ohnehin vermerkt wird. Daher sollte man sich auch eine einmal erhaltene SID solange merken, wie man sie verwenden kann/will ... ständig wiederholte Logins mit entsprechenden Log-Einträgen sind auch nicht das Gelbe vom Ei.
(D) Einfach wirklich konsequent TLS für den Zugriff auf die Box mittels TR-064 verwenden, wann immer das möglich ist ... das schützt auch die übertragenen Daten im LAN vor neugierigen Blicken.
===========================================================
Der Widerspruch, der den FBEditor ganz oben in diesem Beitrag bei mir so "verwirrte", existiert allerdings (m.W.) tatsächlich nur bis Firmware 06.92 - bis zu dieser Version (inkl.) ignoriert nämlich der "ctlmgr" beim Login noch die Forderung nach dem Vorhandensein von Benutzername
und Kennwort, wenn in der "ar7.cfg" im "boxusers"-Abschnitt ein Eintrag "remote_access_id = 98;" existiert (ob die Nummer wirklich unbedingt 98 sein muß, habe ich nie bis zum Ende getestet - dieser Eintrag stammt bei mir noch aus den Anfangszeiten der Benutzerverwaltung) und es einen Benutzer mit dieser ID gibt, der auch noch volle Rechte auf der Box hat (und zwar inkl. Admin-Rechten aus dem Internet, wenn ich mich richtig erinnere), dann akzeptiert die Box auch Anmeldungen mit dessen Kennwort, ohne daß man den entsprechenden Benutzernamen kennen muß.
Das fällt halt beim "normalen" Login übers GUI per Browser nicht weiter auf, weil da ja gleich die Felder passend vorhanden sind in Abhängigkeit vom Anmeldemodus und man ohne die Angabe des Namens meist gar kein Login senden kann ... aber es ist bei mir ein absolut reproduzierbares Phänoment bis zur 113.06.92 und ab der 06.93 dann auch verschwunden. Mal sehen, wann/ob AVM hier "Farbe bekennt" bzw. ob man das dort überhaupt bewußt gefixt hat oder es mehr eine glückliche Fügung war, daß dieses Problem beseitigt wurde.
Jedenfalls ist das auch keine ganz normale Situation für den Editor ... trotzdem sollte er die auch meistern und das heißt eben, daß er den Anmeldemodus korrekt erkennen sollte und auch bei funktionierendem Login über "login_sid.lua" ohne Benutzernamen nicht automatisch davon ausgehen sollte, daß das bei TR-064 auch so klappt. Ich bin vermutlich nicht wirklich der Einzige, der eine solche Konfiguration hat und sie (schon zu Test- bzw. Vergleichszwecken zwischen AVM-Versionen) gerne mal wiederherstellt:
Code:
POST /login_sid.lua HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.8.0_161
Host: 192.168.XXX.1
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 20
sid=0000000000000000
--------------------------------------------------------------------------
HTTP/1.1 200 OK
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/xml
Keep-Alive: timeout=60, max=300
<?xml version="1.0" encoding="utf-8"?><SessionInfo><SID>0000000000000000</SID><Challenge>e8837a18</Challenge><BlockTime>0</BlockTime><Rights></Rights></SessionInfo>
--------------------------------------------------------------------------
POST /login_sid.lua HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.8.0_161
Host: 192.168.XXX.1
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 80
page=/login_sid.lua&response=e8837a18-64862f5958bb6654b2b2882243357cc1&username=
--------------------------------------------------------------------------
HTTP/1.1 200 OK
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/xml
Keep-Alive: timeout=60, max=300
<?xml version="1.0" encoding="utf-8"?><SessionInfo><SID>0253ea26b101c994</SID><Challenge>0f937981</Challenge><BlockTime>0</BlockTime><Rights><Name>Dial</Name><Access>2</Access><Name>App</Name><Access>2</Access><Name>HomeAuto</Name><Access>2</Access><Name>BoxAdmin</Name><Access>2</Access><Name>Phone</Name><Access>2</Access><Name>NAS</Name><Access>2</Access></Rights></SessionInfo>
--------------------------------------------------------------------------
GET /cgi-bin/system_status HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.8.0_161
Host: 192.168.XXX.1
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
--------------------------------------------------------------------------
HTTP/1.1 200 OK
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-type: text/html; charset=iso-8859-1
Keep-Alive: timeout=60, max=300
<html><body>FRITZ!Box 7490-B-152209-030809-642547-367130-197902-1130693-48385-avm</body></html>
Die Box oben hat jedenfalls den Modus "Benutzername und Kennwort benötigt" aktiviert und trotzdem kann man im zweiten Request sehen, daß die Anmeldung erfolgreich ist, obwohl gar kein Benutzername angegeben wurde (und ja, die hat in den 3,75 Jahren ihres Lebens erst 809 Restarts hingelegt) - glücklicherweise klappt(e) dieses Login ohne Benutzernamen aber auch von der WAN-Seite dann nicht, wenn ich mich richtig erinnere.
Daher auch mein Vorschlag, zuerst den tatsächlich verwendeten Anmeldemodus zu ermitteln und dann das erste Login überhaupt erst zu versuchen, wenn alle benötigten Daten beisammen sind.
===========================================================
Sorry, ist länger geworden als gedacht (und bei den Merkwürdigkeiten beim Login mehr Erfahrungsbericht als FBEditor-Problem, selbst wenn der das berücksichtigen sollte) ... ich habe das (mit größeren Unterbrechungen) den halben Tag lang geschrieben und gar nicht bemerkt, wie es immer mehr wurde.
Aber man könnte eben noch so einiges tun, um den FBEditor etwas mehr an die Gegenwart bei den FRITZ!Boxen anzupassen ... das dürfte auch nach wie vor sein Hauptanwendungsgebiet sein, denn die meisten Benutzer werden sicherlich heutzutage die Konfiguration einer eigenen FRITZ!Box mit einer halbwegs aktuellen Version bearbeiten und nicht irgendwelche Dateien (oder alten Boxen) von vor vier und mehr Jahren.
