Neue BetaFirmware: Telefonate per Lua initiieren, Konfiguration DialPort unklar

Moins

muss es einen Logout geben
Das ist zwar "dirty" aber zuverlässig: Sende eine ungültige SID und alle SIDs von dieser IP werden* aus "Sicherheitsgründen" für ungültig erklärt.
...falls der "Logout" so tatsächlich nicht vorgesehen wurde.

* Von der Fritz!Box Logik
 
Das ist zwar "dirty" aber zuverlässig: Sende eine ungültige SID und alle SIDs von dieser IP werden* aus "Sicherheitsgründen" für ungültig erklärt.
...falls der "Logout" so tatsächlich nicht vorgesehen wurde.
* Von der Fritz!Box Logik
Bitte bitte bitte bitte nicht in ordentlicher Software verwenden. Diese Form des "Logouts" führt eben auch wieder zu einem korrekten, aber unpassenden Eintrag im Eventlog und es ist sicherlich überhaupt nicht witzig, wenn dann andere Nutzer Deiner Software vor der Frage stehen, wer da in ihrem Netz mit ungültigen Kontodaten ein Login in die FRITZ!Box versucht.

Wenn es tatsächlich keine TR-064-Funktion dafür gibt und man ein "logout" machen will, damit die SID nicht im Nachhinein von einem Angreifer mißbraucht werden kann (das ist der einzige Grund, der mir jetzt spontan einfällt für zusätzliche Programme), dann ruft man eben das "normale" GUI dafür auf. Der Aufruf der Homepage (/home/home.lua) mit dem Parameter "logout=1" und der SID der eigenen Sitzung erledigt das mindestens genauso zuverlässig und ohne Fehlermeldung im Eventlog. Solange die Session-IDs noch zwischen GUI und TR-064 austauschbar sind (das ist bis zur 06.23 in jedem Falle so, danach habe ich nicht mehr getestet), ist das überhaupt kein Problem, da zwischen den Interfaces zu wechseln.

BTW: Wenn es mal jemand brauchen sollte ... eine gültige SID kann auch für das Login in den FTP-Server (mit den Rechten der Credentials, die zur Anmeldung dieser SID verwendet wurden) "mißbraucht" werden; einfach anstelle des Benutzernamens die SID verwenden und (wenn ich mit richtig erinnere, auch dieser Test war nach dem Erscheinen der 06.23) dann kommt erst gar keine Passwort-Abfrage.
 
Die IP wird aber geloggt, und im lokalen Netz, naja, ist halt "dirty".
Und auf jedenfall besser als die SID einfach nur durch Timeout verfallen zu lassen.
...ich log mich fast nur auf diese Art aus. :D
 
Du bist aber auch keine Software, die andere nachnutzen sollen. Wenn Du das nur für Dich so umsetzt, weißt Du ja auch, wo diese Meldungen herkommen.

Bei mir wäre das (ich habe noch eine interne Firewall inkl. NAT zwischen den Clients und den FRITZ!Boxen) sogar richtig "böse", denn für die FRITZ!Box kommen alle Clientverbindungen von der .2 in ihrem eigenen Subnetz (solange sie lokal und nicht per VPN reinkommen) und da wäre ein Programm auf einem Client, das sich auf diesem Weg "abmeldet" eben vollkommen unbrauchbar, weil es sämtliche Client-Sessions abschießt. Da ist dann "dirty" schon nicht mehr "machtvoll" genug für eine passende Beschreibung in meinen Augen ...

Wie gesagt, es geht (gerade als Programm, wo der "Aufwand" der Eingabe der Adresse ja entfällt) mit kleinstem Aufwand auch "clean".
 
Ok, ist/wäre dann natürlich fahrlässig "dirty".
...wie wäre es mit logout.lua home.lua? Kann die eine SID nicht separiert verungültigen?

"http://fritz.box/login.lua?page=/home/home.lua&logout=1&sid=18f5dd76d5d5ae75"
 
Zuletzt bearbeitet:
"http://fritz.box/login.lua?page=/home/home.lua&logout=1&sid=18f5dd76d5d5ae75"
Warum so kompliziert? Die Redirection für die "login.lua" braucht es gar nicht, s. #22. Man kann problemlos

http://fritz.box/home/home.lua?logout=1&sid=...

aufrufen. Die schickt dann (meiner Erinnerung nach) ohnehin als nächstes ein Redirect (HTTP-Error 303) auf die Login-Seite als Reaktion auf die erfolgreiche Abmeldung, was ein Programm natürlich nicht mehr befolgen muß, wenn es sich abmelden wollte.
 
Naja, kompliziert. Hab doch nur das gepostet was auf Klick nach "Abmelden" in der Adresszeile* erscheint.


* Wenn das Firefoxaddon "Fritz!Box Addon (FF)" benutzt wird. Dann werden (anscheinend) keine Frames benutzt.
 
Hab doch nur das gepostet was auf Klick nach "Abmelden" in der Adresszeile* erscheint.
Dann hättest Du ja auch gleich den Link nehmen können, der sich hinter dem "Abmelden" verbirgt (also beim Klicken dort aufgerufen wird). Das ist dann nämlich genau der, den ich "favorisiert" habe.
 
Da nun das Login-Thema andiskutiert wurde und ich vor habe auch brav Logouts durchzuführen (was ich auch jetzt schon mache) komme ich mal auf meine eigentliche Frage zurück. Wie sollte die Parameterliste korrekt aussehen?

Danke
 
Du hast es ja schon selbst Festgestellt, dial geht per GET,
und den port kann man mit POST setzen.

Bei der alten Funktion konnte man den port und dial in einem POST senden,
und jetzt braucht man für das gleiche zwei aufrufe zuerst ein POST für den port,
danach einen GET für dial.

Port
Code:
          sMode = "POST"
'          sLink = "http://" + sHost + "/fon_num/dial_foncalls.lua"
          sLink = "http://" + sHost + "/fon_num/dial_fonbook.lua"

          sFormdata = ""

          sFormdata = sFormdata + "sid=" + sSID
          sFormdata = sFormdata + "&clicktodial=" + "on"
          sFormdata = sFormdata + "&port=" + sDialPort
          sFormdata = sFormdata + "&btn_apply="

          sTmp = HTTPTransferRT(sMode, sLink, sFormdata)


Dial
Code:
          sMode = "GET"
'          sLink = "http://" + sHost + "/fon_num/dial_foncalls.lua" ' geht nicht mit DialPort
          sLink = "http://" + sHost + "/fon_num/fonbook_list.lua"

          sLink = sLink + "?" + "sid=" + sSID
          sLink = sLink + "&dial=" + sRufnummer

          sFormdata = ""

          sTmp = HTTPTransferRT(sMode, sLink, sFormdata)

Rückgabe bei Dial
Code:
{
"dialing": "**2", 
"orig_port": "50"
}

Hangup
Code:
          sMode = "GET"
'          sLink = "http://" + sHost + "/fon_num/dial_foncalls.lua" ' geht nicht mit DialPort
          sLink = "http://" + sHost + "/fon_num/fonbook_list.lua"

          sLink = sLink + "?" + "sid=" + sSID
          sLink = sLink + "&hangup="

          sFormdata = ""

          sTmp = HTTPTransferRT(sMode, sLink, sFormdata)

Rückgabe bei Hangup
Code:
{
"dialing": false, 
"orig_port": "50"
}

Wahl per Lua ab xxx.06.25 mit PHP hier: FbDial_Lua.php/FbDialHangup_Lua.php
 
Zuletzt bearbeitet:
komme ich mal auf meine eigentliche Frage zurück. Wie sollte die Parameterliste korrekt aussehen?
Was willst Du denn wissen?

In #19 habe ich die Frage gestellt, auf welcher Schnittstelle das arbeiten soll. Wenn es x_contactSCPD ist (die Bestätigung steht noch aus), habe ich die (hoffentlich) korrekte Schnittstellenbeschreibung verlinkt. Dort findest Du auf Seite 5 (Punkt 2.12) die Beschreibung der Funktion GetPhonebook. Siehst Du dort irgendwo die von Dir angegebenen Eingabeparameter "password" und/oder "login"? Ich nicht und wahrscheinlich war das auch der Grund, warum ich in #19 schrieb

PeterPawn schrieb:
Die Authentifizierung für so einen SOAP-Request sollte (meines Wissens) auf der Transportebene erfolgen, damit haben Parameter wie "login" und "password" als Inhalt des Requests nur dann einen Sinn, wenn sie zu der Parameterliste der aufgerufenen Funktion gehören.

Hast Du mal einen Blick in die ebenfalls von mir verlinkte TR-064-Spezifikation gewagt? Selbst wenn man keine Lust hat, das komplette Dokument richtig zu lesen, so finden sich doch ab Seite 87 Beispiele, die auch Funktionen mit Eingabeparametern umfassen. Das "SetUserName" auf Seite 88 dürfte zweifellos ein Funktionsaufruf mit einem Eingabeparameter (NewUserName) sein. Das nachfolgende Beispiel ist ein Aufruf einer Funktion mit einem Ausgabeparameter.

Wird da irgendwo im Request angegeben, daß es diesen Parameter in der Response geben wird? Damit dürfte doch die Vermutung

Kruemelino schrieb:
Ich ahne meinen Fehler, ich darf nicht nur die "in"-Argumente in die XML-Überführen sondern muss auch stets die "out"-Argumente senden?

etwas an Wahrscheinlichkeit einbüßen.

Wenn Du bisher beim Aufruf von Funktionen ohne Eingabeparameter tatsächlich bei jedem Request "password" und "login" angegeben haben solltest und die FRITZ!Box hat Dir trotzdem (fehlerfrei) geantwortet, dann dürfte das eher ein Fehler im Request-Parser der FRITZ!Box sein, der dann für Funktionen ohne erwartete Eingabeparameter wahrscheinlich gar nicht erst die angegebenen Parameter prüft.

Meine Frage in #19 war auch nicht, ob der Request "hart kodiert" war, sondern ob er "von Hand" kodiert wurde - sprich, nicht mit einem ordentlichen Parser für eine SOAP-Schnittstellendefinition erzeugt wurde, sondern durch Hinzufügen von XML-Entities über das DOM (im besseren Fall) oder gar durch das Klittern von Strings zu einer XML-Struktur (das ist so ziemlich der "worst case").

Ich wiederhole mich ja nur ungern, aber wenn Du auf die Webservice-Klassen aus der WCF anstelle einer eigenen Implementierung von SOAP-Requests gesetzt hättest (und so richtig weißt Du ja offenkundig noch nicht, wie das SOAP-Protokoll aussieht), dann würden sich diese Fragen gar nicht stellen ... wenn Du tatsächlich unbedingt selbst ein "low level SOAP interface" programmieren willst, solltest Du vielleicht vorher einen Blick in die betreffenden Standards werfen, z.B. hier.

Aus Punkt 7.1 der SOAP-Spezifikation:

The method invocation is viewed as a single struct containing an accessor for each [in] or [in/out] parameter.
[...]
The method response is viewed as a single struct containing an accessor for the return value and each [out] or [in/out] parameter.

Ich finde auch da keinen Hinweis darauf, daß ein reiner "out"-Parameter irgendwie in einem Request enthalten sein darf und da so eine Schnittstellendefinition nun mal eine eindeutige "Signatur" so einer Methode darstellt, kann man auch nicht einfach weitere Parameter dazudichten.

Wenn also die FRITZ!Box Dir da tatsächlich solche Requests abgekauft hat, ist das ein Fehler der FRITZ!Box. Ob das allerdings so war, kann ich anhand der Beschreibung im Text auch nur raten, denn irgendwie finde ich in Deinen ganzen Beiträgen kein Beispiel, wie es bei Dir funktioniert haben soll bzw. was Du bisher gemacht hast ... das einzige ist das nicht funktionierende Beispiel aus #18.

Ich verstehe ja, daß das nur ein Hobby ist und verlange auch beileibe nicht, daß sich jeder mit allen diesen Themen auskennen muß. Aber auf der anderen Seite heißt Hobby eben auch, daß man sich etwas intensiver damit beschäftigen muß und da kann man Dir aus meiner Sicht nur mit guten Ratschlägen (und die Benutzung der Webservice-Klassen der WCF (die ist Bestandteil des .NET-Frameworks und keine Zusatzbibliothek) anstelle einer eigenen Implementierung ist und bleibt für mich die beste Empfehlung an dieser Stelle) und entsprechenden Literaturhinweisen helfen ... lesen mußt Du dann schon selbst.

Und wenn wir uns dann hier in "Deinem Thread" über Login/Logout austauschen und davon ausgehen, daß Du die bisherigen Antworten auch gelesen hast (und offensichtlich auch verstanden, denn konkrete Rückfragen zum Geschriebenen finde ich auch nicht) und fleißig beim Programmieren bist, dann weiß ich halt nicht so genau, was Du da anderes erwartet hast. Ich hoffe mal nicht, daß die Feststellung

Kruemelino schrieb:
Du schreibst aber viel ;)

am Ende heißen sollte, daß es zuviel war und Du es deshalb nicht (in Gänze) gelesen hast ... denn dann hätte ich Dir mit diesem Beitrag ja wieder eine ähnliche Last aufgebürdet.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

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.