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 <[email protected]>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 <[email protected]> > To: [email protected] > 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 <[email protected] > >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 <[email protected]> > > > To: [email protected] > > > 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
