[Python-SDK]: Callback: Empfang von Nachrichten funtioniert nicht

Stelle deine Frage öffentlich an die Threema-Forum-Community - über 4.800 Mitglieder helfen dir weiter. > Frage stellen <

    Servus an das Forum,

    ich versuche mittels einer End-to-End ID Nachrichten zu empfangen.

    Das Versenden funktioniert einwandfrei.

    Umgebung:

    - Python SDK von github (https://github.com/lgrahl/threema-msgapi-sdk-python), callback.py wird verwendet

    - Python Version: 3.6.6

    - Betriebssystem: Win 10 (1909)

    - SSL Zertifikat und Schlüssel (von Let's Encrypt, gültig bis Mai 2020) ist vorhanden und wird vom Provider akzeptiert.

    Ich hoffe ich habe dann in der callback.py alles richtig eingetragen und versuche dann von meiner Android Threema App

    an meinen PC eine Nachricht zu schicken. Es geschieht aber gar nichts.

    Fragen:

    - wie kann man prüfen wie weit die zu empfangende Nachricht überhaupt kommt

    - wie muss der Eintrag des Eingabefeldes URL für eingehende Nachrichten auf der Seite Threema.Gateway -> ID bearbeiten lauten?

    Vielen Dank

    Die URL muss so aussehen: https://<deine-domain>:8443/gateway_callback

    Es sei denn, du hast den Port oder die Route im Code angepasst.

    Ich würde erstmal testen, ob dein Server so überhaupt erreichbar ist. Einfach einen POST-Request an die oben genannte URL schicken.

    Ich musste den Port wieder auf Standard 443 zurück setzen. Liegt wohl am Provider.

    Ich bekomme dann das:

    Weiß jetzt nicht mehr was ich tun soll

    Der Eintrag für die E2E id lautet: https://www.xyz:443/gateway_callback

    Wenn es eine noch kompliziertere Lösung gibt um Nachrichten zu empfangen dann bitte her damit

    Zitat von MasterDesGateways

    Ich musste den Port wieder auf Standard 443 zurück setzen. Liegt wohl am Provider.

    Das kann ich mir nicht vorstellen. Vielleicht hast du eine Firewall aktiv?

    Wenn 404 kommt, dann ist das entweder nicht der Server, den du glaubst anzusprechen, oder du hast die Route angepasst. Probiere mal:

    Code
    curl -v -X POST -d 'foo' https://<hostname>:<port>/gateway_callback

    Das sollte ungefähr folgenden Output ergeben, wenn der Callback-Server antwortet:

    < HTTP/1.1 400 Bad Request
    < CONTENT-LENGTH: 0
    < CONTENT-TYPE: application/octet-stream
    < DATE: Wed, 19 Feb 2020 16:06:12 GMT
    < SERVER: Python/3.8 aiohttp/2.3.10

    Ich habe dazu eine generelle Frage:

    Warum hat man so eine ausladende Lösung gewählt?

    Ich selbst habe von Web-Programmierung wenig Ahnung, das sollen die Jungen erledigen.

    Ich musste mir diese Homepage auch noch "leihen", ich selbst habe gar keine, ich erstelle dieses Projekt für einen Bekannten im Auftrag.

    Wieso zieht man beispielsweise nicht die Telefonnummer zur Validierung des Users heran?

    Der Telefonclient (die App, bin halt altmodisch) braucht all diese Einstellungen ja auch nicht.

    Threema ist bewusst nicht an eine Telefonnummer gebunden. Die Threema ID ist anonym. Ich verstehe aber auch nicht den Zusammenhang zum Gateway.

    Ich finde das Verfahren nicht ausladend, bis auf den Fakt, dass man einen öffentlich erreichbaren Server aufstellen muss, da die Kommunikation bidirektional aufgebaut werden kann. Das wurde aus Ressourcengründen so gemacht (worüber man sich allerdings auch streiten kann). Im Grunde handelt es sich hier um Peer-to-Peer-Kommunikation. Mir wäre eine Client-to-Server-Kommunikation in dem Fall lieber, da so keine Firewalls geöffnet werden müssten und man keinen öffentlich erreichbaren Server braucht. Den Wunsch kann man gerne an Threema herantragen.

    Was ist denn genau dein Ziel? Was willst du implementieren?

    Das Python SDK für Threema Gateway ist primär das: Ein Software Development Kit. Es ist dafür da, dass Software-Entwickler eine eigene Lösung basierend auf der Gateway-API entwickeln. Es bietet dafür primär Primitiven, d.h. Funktionen zur Ver- und Entschlüsselung von Nachrichten sowie Hilfstools zur Kommunikation mit dem Server. Es ist keine Fertiglösung, sondern kann verwendet werden um eine solche zu bauen.

    Zitat von lgrahl

    Threema ist bewusst nicht an eine Telefonnummer gebunden. Die Threema ID ist anonym. Ich verstehe aber auch nicht den Zusammenhang zum Gateway.

    Ich finde das Verfahren nicht ausladend, bis auf den Fakt, dass man einen öffentlich erreichbaren Server aufstellen muss, da die Kommunikation bidirektional aufgebaut werden kann. Das wurde aus Ressourcengründen so gemacht (worüber man sich allerdings auch streiten kann). Im Grunde handelt es sich hier um Peer-to-Peer-Kommunikation. Mir wäre eine Client-to-Server-Kommunikation in dem Fall lieber, da so keine Firewalls geöffnet werden müssten und man keinen öffentlich erreichbaren Server braucht. Den Wunsch kann man gerne an Threema herantragen.

    Das wäre nicht schlecht, denn wie gesagt, selbst heutzutage verfügen noch einige über keine eigene HP.

    Der Aufwand auf Kundenseite ist da nicht unerheblich.

    Zur Telefonnummer / ID: Hier könnte man ja mit Hashes arbeiten. Wie gesagt, der Smartphone Client (die App) braucht all das (anscheinend?)

    ja auch nicht.

    Zitat von MasterDesGateways

    Zur Telefonnummer / ID: Hier könnte man ja mit Hashes arbeiten. Wie gesagt, der Smartphone Client (die App) braucht all das (anscheinend?)

    ja auch nicht.

    Nochmal: Das Verlinken der Telefonnummer in Threema ist rein optional.

    Die Threema App kommuniziert nicht über das Gateway, sondern über den Chat Server. Darüber hinaus authentifiziert sich die Threema App rein mit dem Private Key, der durch die Registrierung fest an die Threema ID gebunden wurde. Analog ist es so beim Gateway, wobei die Authentifizierung zusätzlich noch ein Secret benötigt.

    curl liefert das auf Port 443:

    --- curl Start

    C:\Users\<DerUser>>curl -v -X POST -d 'bla3000' https://www.<DerServer>.de:443/gateway_callback

    Note: Unnecessary use of -X or --request, POST is already inferred.

    * Trying <DieAdresse>...

    * TCP_NODELAY set

    * Connected to www.<DerServer>.de (<DieAdresse>) port 443 (#0)

    * schannel: SSL/TLS connection with www.<DerServer>.de port 443 (step 1/3)

    * schannel: checking server certificate revocation

    * schannel: sending initial handshake data: sending 186 bytes...

    * schannel: sent initial handshake data: sent 186 bytes

    * schannel: SSL/TLS connection with www.<DerServer>.de port 443 (step 2/3)

    * schannel: failed to receive handshake, need more data

    * schannel: SSL/TLS connection with www.<DerServer>.de port 443 (step 2/3)

    * schannel: encrypted data got 1832

    * schannel: encrypted data buffer: offset 1832 length 4096

    * schannel: sending next handshake data: sending 126 bytes...

    * schannel: SSL/TLS connection with www.<DerServer>.de port 443 (step 2/3)

    * schannel: encrypted data got 274

    * schannel: encrypted data buffer: offset 274 length 4096

    * schannel: SSL/TLS handshake complete

    * schannel: SSL/TLS connection with www.<DerServer>.de port 443 (step 3/3)

    * schannel: stored credential handle in session cache

    > POST /gateway_callback HTTP/1.1

    > Host: www.<DerServer>.de

    > User-Agent: curl/7.55.1

    > Accept: */*

    > Content-Length: 9

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

    >

    * upload completely sent off: 9 out of 9 bytes

    * schannel: client wants to read 102400 bytes

    * schannel: encdata_buffer resized 103424

    * schannel: encrypted data buffer: offset 0 length 103424

    * schannel: encrypted data got 520

    * schannel: encrypted data buffer: offset 520 length 103424

    * schannel: decrypted data length: 491

    * schannel: decrypted data added: 491

    * schannel: decrypted data cached: offset 491 length 102400

    * schannel: encrypted data buffer: offset 0 length 103424

    * schannel: decrypted data buffer: offset 491 length 102400

    * schannel: schannel_recv cleanup

    * schannel: decrypted data returned 491

    * schannel: decrypted data buffer: offset 0 length 102400

    < HTTP/1.1 301 Moved Permanently

    < Date: Thu, 20 Feb 2020 16:41:02 GMT

    < Content-Type: text/html; charset=iso-8859-1

    < Content-Length: 255

    < Connection: keep-alive

    < Server: Apache

    < Location: https://www.<DerServer>.de/gateway_callback/

    <

    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

    <html><head>

    <title>301 Moved Permanently</title>

    </head><body>

    <h1>Moved Permanently</h1>

    <p>The document has moved <a href="https://www.<DerServer>.de/gateway_callback/">here</a>.</p>

    </body></html>

    * Connection #0 to host www.<DerServer>.de left intact

    curl liefert das auf Port 8443 obwohl ich es auf dem Router und in der Firewall frei geschaltet habe

    C:\Users\<DerUser>>curl -v -X POST -d 'bla3000' https://www.<DerServer>.de:8443/gateway_callback

    Note: Unnecessary use of -X or --request, POST is already inferred.

    * Trying <DieAdresse4>...

    * TCP_NODELAY set

    * Trying <DieAdresse6>...

    * TCP_NODELAY set

    * connect to <DieAdresse6> port 8443 failed: Network unreachable

    * connect to <DieAdresse4> port 8443 failed: Connection refused

    * Failed to connect to www.<DerServer>.de port 8443: Connection refused

    * Closing connection 0

    curl: (7) Failed to connect to www.<DerServer>.de port 8443: Connection refused

    Dann muss man sich doch die Frage stellen warum das irgendein Apache Server ist und nicht der Callback Server.

    Die Konfiguration scheint ja zu stimmen.

    Mir als Internet Laie ist eh nicht ganz klar wie man über diesen Konstrukt einen Server erreichen soll den man gar nicht kennt

    Ich hab's jetzt mal so versucht (geht auch nicht, will eigentlich nur von meinem Android Threema Client eine Nachricht an mein GW Konto schicken, sonst nichts):

    threema-callback-server -v 7 serve *<Meine GW ID> <Mein GW Secret> private:<mein privater Threema Key> certificate.crt -k private.key

    Starting

    Started

    Muss man sonst noch was einstellen? Laut Quellcode ist ja der Port default auf 443 eingestellt

    Die Konfiguration im Threema GW Interface sieht so aus:

    Secret <Mein GW Secret>

    Public Key <Der pub Key>

    URL für eingehende Nachrichten https://www.<DerServer>.de:443/gateway_callback

    Muss ich auf <DerServer> das Verzeichnis gateway_callback erstellen?

    Zitat von MasterDesGateways

    Dann muss man sich doch die Frage stellen warum das irgendein Apache Server ist und nicht der Callback Server.

    Keine Ahnung, du musst doch wissen was auf deinem Server läuft?

    Ich weiss ehrlich gesagt nicht, wie ich dir weiter helfen soll. Auf dem Server selbst sollte folgendes den oben genannten Output erzeugen:

    Code
    curl -v -k -X POST -d 'foo' https://localhost:<port>/gateway_callback

    Ist das so, bist du schon einen Schritt weiter. Dann gilt es herauszufinden, warum dein Server nicht von aussen erreichbar ist.

    Jetzt habe ich das Ganze verstanden und somit ist für mich die Sache gestorben.

    Wir werden halt einen anderen sicheren Messenger wählen.

    Nochmal: Es ist nicht "mein" Server, sondern der Server des Providers. Deshalb hat es mich ja das Ganze von Anfang an gewundert.

    Ich komme da ja gar nicht auf eine Konsole.

    Auf so eine krude Lösung muss man mal kommen.