Qtwebsocket will be provided by the next official Qt 5.3, I would prefer wait under jqt uses that version before reviewing how to implement low level functions. On Feb 12, 2014 3:07 AM, "Joe Bogner" <joebog...@gmail.com> wrote:
> If QtWebSocket is being used then it should be accessible through > http://qt-project.org/doc/qt-4.8/qabstractsocket.html#peerAddress of the > socket that is returned from QtWebsocket::QWsSocket* clientSocket = > server->nextPendingConnection();. I'm assuming it's implemented along the > lines of > > https://gitorious.org/qtwebsocket/qtwebsocket/source/75f9105977502b5ec7ae405820b112c7c576b10a:Example/Server/Server.cpp#L44 > > > Perhaps pushing the peer address string to a global variable like wss0_jrx_ > would be enough > > > > > > On Tue, Feb 11, 2014 at 12:33 PM, Pascal Jasmin <godspiral2...@yahoo.ca > >wrote: > > > 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 > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
