I'd like to make an application that allows public connections, and in fact is peer to peer so the world can run a node/the code. Websockest solves an issue of allowing more than 64 connections on windows, and even 1024 connections on linux/mac/android. Websockets also transparently handles large block transfers.
I've posted J code before on an authentication layer in J, and managing multiple connections, and walling off code access to clients. ( http://www.jsoftware.com/jwiki/PascalJasmin/OOP%20scheduler%20and%20jsockets ) The one requirement though is that there should be some limit on login attempts per IP, and some way of detecting obvious abuse such as millions of login attempts or sending terrabytes in response to a login prompt. "There is REMOTE_ADDR" no way to access from J yet? " put a websocket server behind a webserver or other proxy. What we candone is unlikely to be better than those specialised products." A user code solution is straightforward if REMOTE_ADDR is available. Its also preferable if the application provides default code for dealing with access limits and doesn't require any user decisions/settings, much less installing firewalls and forwarding ports. Its especially preferable if the application is the only server a user is expected to be running. LOCAL_ADDR is marginally helpful too. ----- Original Message ----- From: bill lam <bbill....@gmail.com> To: programm...@jsoftware.com Cc: Sent: Tuesday, February 11, 2014 11:29:50 AM Subject: Re: [Jprogramming] QT websockets There is REMOTE_ADDR and also some othe cgi environment variables but I'm not sure if webosket protocol is required to provide cgi environment variables. If security is a real concern, I guess it is best to put a websocket server behind a webserver or other proxy. What we can done is unlikely to be better than those specialised products. Вт, 11 фев 2014, Joe Bogner писал(а): > 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 -- 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
