Hallo,
Ich habe eine Webseite die über WebSocket mit Symcon kommuniziert und ein selbstgeschriebenes Modul. Ist es möglich in dem Modul eine Nachricht über WebSocket zu versenden? Und wenn ja, wie?
Hallo,
Ich habe eine Webseite die über WebSocket mit Symcon kommuniziert und ein selbstgeschriebenes Modul. Ist es möglich in dem Modul eine Nachricht über WebSocket zu versenden? Und wenn ja, wie?
Wer ist Client und wer Server?
Symcon kann als IO Websocket Client und ja, da kannst du wie immer über den Datenaustausch senden/empfangen.
Michael
Symcon ist in dem Fall der Server
D.h. du hast einen Webhook in Symcon, an welchen du die Daten empfängst?
Dann benutze doch einfach die Funktionen für das WebHook-Control
Michael
Ich muss das Thema nochmal nach vorne holen, da ich irgendwie auf dem Schlauch stehe. Über welchen Kanal/ javascript-Befehl kann ich die Nachricht beim Client empfangen? Ich war davon ausgegangen, dass das über den WebSocket funktioniert. Da sehe ich die Nachricht aber nicht.
Normalerweise nutze ich
var connection = new WebSocket('wss://127.0.0.1:3777/wfc/12345/api/', [encodeURIComponent(btoa('webfront:webfrontpw'))]);
habe aber alternativ auch
var connection = new WebSocket('wss://127.0.0.1:3777/api/', [encodeURIComponent(btoa('email:fernzugriffpw'))]);
probiert. Ich finde die gesendete Nachricht aber nicht im Datenstrom. Was muss ich tun?
Grüße
Jürgen
ich habe mir jetzt mit einem leeren WebFront und
WFC_SendNotification($webFrontID, "VM_UPDATE", json_encode($msg),"",1);
geholfen. Das funktioniert soweit sehr gut. Dennoch würde mich interessieren, wie der Befehl
WC_PushMessage(12345, "/hook/test/", "Hallo Welt");
gedacht ist. Wie man damit sendet, ist ja gut beschrieben und das funktioniert auch. Aber wie kann ich die Nachricht am Hook-Client empfangen? @paresy kannst du das kurz erläutern?
Grüße
Jürgen
Na der Client muss sich auch auf /hook/test
verbinden und nicht auf die Symcon API.
Michael
Das heißt auf
var connection = new WebSocket('wss://127.0.0.1:3777/hook/test/', []);
(also ohne api und ohne Passwort)? Das muss ich gleich nochmal ausprobieren. Auf /hook/test war ich gekommen, hatte da aber noch /api/ angehängt und dann kam da nichts…
Danke
Jürgen
Ja. Der webhook ist davon unabhängig.
Eine Authentifizierung muss man selbst realisieren.
Beispiel dazu gibt es ja in der Symcon Doku des webhook.
Michael
Ja, die webhook-Authentifizierung habe ich umgesetzt. Das ist kein Problem. Beim WebSocket hätte ich keine Idee, wie das funktionieren könnte….
prima, Daten kommen an. Dann fehlt nur die Umsetzung des Passworts für den WebSocket.
Kannst du mir da auf die Sprünge helfen?
Grüße
Jürgen
Habe es mit dem websocket nie getestet. Allerdings sollte es wie bei der http Authentifizierung gehen.
Wobei ich jetzt nicht weiß, woher das Script wissen soll ob es eine neue Verbindung ist, oder eine bestehende.
Michael
ja genau. Die Authentifizierung muss beim Anmelden des Clients an den WebSocket passieren. Da müsste es einen Befehl, wie
WC_SetPassCode(12345, "/hook/test/","ganzGeheim");
geben. Den kenne ich aber nicht. @paresy gibt es da etwas, oder könntest du so einen Befehl ergänzen?
Grüße
Jürgen
Ne, wieso?
Der Client sendet die Zugangsdaten und im Script hier dem Webhook musst du das auswerten.
Die werden auch nur beim Verbindungsaufbau vom Client gesendet. Danach ist es ja eine stehende Verbindung.
Die Frage ist halt, wie kannst du im Script erkennen ob die Verbindung neu ist (also mit Zugangsdaten) oder vorhanden (keine Ahnung was dann in $_SERVER steht).
Michael
das ist ja cool. Mit welchem Befehl kann ich die lesen?
Schau mal hier:
Michael
sorry, das habe ich jetzt nochmals intensiv durchgelesen. Aber zum Absichern des WebSockets finde ich da nichts. Jeder, der möchte, kann sich auf den Kanal draufschalten und die Nachrichten vom Server empfangen.
So ca in der Mitte…
das ist für den WebHook, aber nicht für den WebSocket
Ja, ich würde aber erwarten das beim Verbindungsaufbau auch das Verarbeitungsskript getriggert wird (was aktuell nicht passiert) und nicht nur beim Datenempfang.
@paresy Warum kann man hier nicht eingreifen und z.B. Clients mit header('HTTP/1.0 401 Unauthorized');
abwerfen, bevor Symcon das Upgrade der Connection bestätigt?
Michael