The websocket demo works well and I can see a lot of potential with it. Thank you! I also agree with Pascal that it would be useful to get information about the connecting socket (e.g. originating IP address). The most basic security workaround is to add a firewall rule to prevent connections on the port from outside interfaces. It might be helpful to be able to bind to a specific IP/interface like a socket too.
On Tue, Feb 11, 2014 at 9:21 AM, Pascal Jasmin <godspiral2...@yahoo.ca>wrote: > nodeJS calls the function remoteAddress, and pants calls it getpeername. > > In terms of "security already handled by websocket protocol", I can see a > necessity for a user code authentication layer, but passwords might be > compromised, and an IP could attempt millions of logins. The millions of > login attempts could be an intentional DOS event. There is a simplicity to > requiring 192.168.x.x IPs for "root" (privileged) user code access to > server or simply any access. > > Running the demo for instance allows the world to execute ". on your > machine. ? > > > > ----- Original Message ----- > From: bill lam <bbill....@gmail.com> > To: programm...@jsoftware.com > Cc: > Sent: Tuesday, February 11, 2014 3:48:36 AM > Subject: Re: [Jprogramming] QT websockets > > I think those low level functions are not part of websocket > spec. Security is already handled by websocket protocol. > > Since J is single thread, those globals will not cause any > trouble. A handler can erase them if they are no longer used. > > Anyways, IMO, to compare socket with websocket is analogous > to compre an apple with an pineapple. > > Пн, 10 фев 2014, Pascal Jasmin писал(а): > > demos work fine. (and avast makes no complaints about the zip version of > J8) > > > > I notice that sdgetpeername and sdgetsockname do not work on websockets > (understandable if they are not sockets) and there is no QT equivalent for > the functions. > > > > Is that something not implemented by QT, or not implemented by the J > version? > > > > I can provide use cases, but the most obvious ones are centered around > security and logging, authentication, and tunneling or calling back > disconnected nodes based on IP addresses. > > > > I notice that wss0_jrx_ , wss1_jrx_ are "global" variables that persist > through connect/disconnect (calls through handler). Perhaps these > parameters could be set to peer/sock name/IP for the onopen event, if a > qtgetpeername/sockname is somehow difficult? > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
