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.
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?
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
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
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
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.
Was ist denn genau dein Ziel? Was willst du implementieren?
--- cut ---
Habe ich in der ersten Nachricht des Threads dargelegt
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.
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
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
