Tester gesucht

[TS]

Hello,

nochmal wiederholt. Es steht ja schon weiter unten, dass ich unter getscript.de Tester suche :-)

Liebe Grüße
Tom S.

[Matthias Apsel]

Hallo TS,

nochmal wiederholt. Es steht ja schon weiter unten, dass ich unter getscript.de Tester suche :-)

Connecting...
Disconnected.

FF 52.0.1 WIN 10

Bis demnächst
Matthias

[TS]

Hello,

nochmal wiederholt. Es steht ja schon weiter unten, dass ich unter getscript.de Tester suche :-)

Connecting...
Disconnected.

FF 52.0.1 WIN 10

Nanu, bei mir funktioniet das, auch per Tablet und UMTS. Auch bei IP 178.24.. mit Text "lklk+" ist was angekommen.

Liebe Grüße
Tom S.

[TS]

Hello,

nochmal wiederholt. Es steht ja schon weiter unten, dass ich unter getscript.de Tester suche :-)

Connecting...
Disconnected.

FF 52.0.1 WIN 10

Win 10 musst Du vermutlich den Port (hier 9300) gezielt freigeben?

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Win 10 musst Du vermutlich den Port (hier 9300) gezielt freigeben?

Nö, du "musst" einen Reverse Proxy aufsetzen, der WebSocket kann. Es ist nicht anzunehmen, dass in Firmen mit auf Sicherheit bedachten IT-Abteilungen andere Ports als 80 und 443 nach außen gelassen werden.

dedlfix.

[Websocket-Tester]

Achso. Kann sein.
Aber der Port wird doch von innen angefordert mit dem JS-Script und newWebSocket()?

Da sollte das doch gehen...

[dedlfix]

Tach!

Aber der Port wird doch von innen angefordert mit dem JS-Script und newWebSocket()?
Da sollte das doch gehen...

Es kommt auf die Firewall-Einstellungen an. Und die sind mitunter auf 80 und 443 für ausgehenden Web-Verkehr beschränkt.

dedlfix.

[pl]

Test erfolgreich!

Mit dem letzten lauffähigen FF auf XP.

Und jetzt Du, teste mal meinen WebsocketChat, superflink das Teil, sogar mit Klingel 😉

Leider kann ich den nicht durchgängig laufen lassen. MfG

[1unitedpower]

Und jetzt Du, teste mal meinen WebsocketChat, superflink das Teil, sogar mit Klingel 😉

Zwei Punkte zur Sicherheit:

"Private" Nachrichten werden trotz ihres Namens gebroadcastet, das geht so gar nicht. Habe mich zum Testen mit drei Nutzern "test1", "test2" und "test3" eingeloggt und eine private Nachricht von test3 and test2 gesendet. Bei test1 habe ich den Socket mit den Entwicklertools beobachtet und konnte die private Nachricht lesen, von der ich weder Absender noch Empfänger war.

Außerdem kann ich im Socket Session-IDs von anderen Teilnehmern sehen…

[pl]

"Private" Nachrichten werden trotz ihres Namens gebroadcastet

nein, guckst Du:

                if(my $tosid = $msgobj->{tosid}){
                    for ($conn->server->connections){
                        next if $_->{SID} ne $tosid;
                        $_->send_utf8($msg);    
                    }
                }
                else{
                    $_->send_utf8($msg) for $conn->server->connections;      
                }

Broadcast ist im else{}-Zweig.

Außerdem kann ich im Socket Session-IDs von anderen Teilnehmern sehen

Die siehst du auch schon im Browser /HTML. Die gibt es nur wegen der Zuordnung, die SID wird bereits beim Verbindungsaufbau mitgenommen damit die auch auf dem Server bekannt ist. Diese SID gibt es nur einmal im Serverprozess, das Mitlesen von Nachrichten die nicht an die eigene SID gerichtet sind, ist gar nicht möglich.

Deinen Test betreffend: Verbunden waren stets test1, test2 oder test3 nacheinander, also nicht gleichzeitig, was das Serverlog bestätigt.

Log-Auszug:

{"sid":"c835beb5790d9b883eb1393803441ef4","nickname":"test3","time":"15:01:28","tosid":"c835beb5790d9b883eb1393803441ef4","joined":"olf ? test3","mesg":"private test 3 -> 2"}

Die Private Nachricht ist an dieselbe SID gegangen.

MfG

[1unitedpower]

Die Private Nachricht ist an dieselbe SID gegangen.

Dann steckt der Bug scheinbar in der Session-ID-Generierung. Mit unterschiedlichen Credentials sollte man auch unterschiedliche IDs bekommen. Bzw. solltest du die Session-ID nach dem Erlangen neuer Rechte mindestens auffrischen. Habe den gleichen Test gerade nochmal durchgeführt und ich konnte die Nachricht schon wieder lesen. Wieso benutzt du für Sockets überhaupt Session-IDs? Anders als HTTP sind WebSockets stateful, man braucht diese Krücke also gar nicht.

[pl]

Solange Du keine neue Browsersession eröffnest, bleibt die Session-ID dieselbe, ein Bug ist das nicht. Und wie bereits gesagt, jeder der reinkommt, braucht eine eindeutige Kennung bereits beim Verbindungsaufbau damit private Nachrichten möglich sind. MfG

[TS]

Hello,

Solange Du keine neue Browsersession eröffnest, bleibt die Session-ID dieselbe, ein Bug ist das nicht. Und wie bereits gesagt, jeder der reinkommt, braucht eine eindeutige Kennung bereits beim Verbindungsaufbau damit private Nachrichten möglich sind.

Wann, unter welchem Protokoll und Port wird die Session-ID denn angelegt?

Ich weiß nicht, wie schnell ich diese WS-API duchschaut habe, aber so wie es aussieht, kann ich sehr wohl auch unter derselben IP (NAT) mehrere User-Sockets mit dem Server-Socket verbinden und auch unterscheiden.

Ich bastel mal weiter daran und dann gucken wir mal, ob auch private Nachrichten möglich sind.

Liebe Grüße
Tom S.

[pl]

Guckst Du HTML, Port ist 443. Die SID wird bei mir per HTTP ausgehandelt. MfG

[dedlfix]

Tach!

Ich weiß nicht, wie schnell ich diese WS-API duchschaut habe, aber so wie es aussieht, kann ich sehr wohl auch unter derselben IP (NAT) mehrere User-Sockets mit dem Server-Socket verbinden und auch unterscheiden.

Das ist eins der wesentlichsten Merkmale von TCP/IP-Kommunikation.

Ich bastel mal weiter daran und dann gucken wir mal, ob auch private Nachrichten möglich sind.

Natürlich, ist ja eine direkte Verbindung und kein Broadcast.

dedlfix.

[TS]

Hello,

Ich weiß nicht, wie schnell ich diese WS-API duchschaut habe, aber so wie es aussieht, kann ich sehr wohl auch unter derselben IP (NAT) mehrere User-Sockets mit dem Server-Socket verbinden und auch unterscheiden.

Das ist eins der wesentlichsten Merkmale von TCP/IP-Kommunikation.

Ich bastel mal weiter daran und dann gucken wir mal, ob auch private Nachrichten möglich sind.

Natürlich, ist ja eine direkte Verbindung und kein Broadcast.

Das hängt ganz davon ab, wie man den Port mit daten beaufschlagt.

• 1. PHP-Manual
• 2. PHP-Manual

Und in der Beispielanwendung werden die Meldungen auch an alle gesendet.

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Ich bastel mal weiter daran und dann gucken wir mal, ob auch private Nachrichten möglich sind.

Natürlich, ist ja eine direkte Verbindung und kein Broadcast.

Das hängt ganz davon ab, wie man den Port mit daten beaufschlagt.

Nein, Broadcast ist nur im lokalen Netz möglich.

Und in der Beispielanwendung werden die Meldungen auch an alle gesendet.

Garantiert mit einer Schleife über alle aktuellen Verbindungen.

dedlfix.

[pl]

Sobald Du Meine Chat Seite aufrufst, wird die Websocket-Verbindung hergestellt. Zu diesem Zeitpunkt steht der Nickname noch gar nicht fest, daher übergebe ich hier eine ID die bereits vorher feststeht und auch dem Browser bekannt ist als Session-ID. Infolge der Übergabe bereits beim Verbindungsaufbau ist diese ID auch serverseitig bekannt und eine eindeutige Zuordnung bidirektional möglich.

Wenn Du eine andere Lösung für diesen Challenge hast, lass es mich wissen 😉

Viel Erfolg!

PS: Der WebsocketChallenge ist in Wikipedia beschrieben, der Challenge an sich ist pure HTTP. Wenn es Dir gelingt, Sec-WebSocket-Key bzw. Sec-WebSocket-Accept so auszukoppeln, dass es in der Socket-Pipe verwendet werden kann, kannst Du selbstverständlich auf eine eigene SID verzichten. Evntl. gibt es ja mittlerweile Methoden für das Objekt und dann isses noch die Frage was Du am Server machen kannst.