You surely can filter the hosts (see the setParanoid method of WebServer) but indeed, there is nothing possible with the very developer friendly approach.
An easy extension might be to have another interface than the XmlRpcHandler handler interface where the execute(String method, Vector params) would be exteneded to execute(methid, params, socket) or something better abstracting the remote host. It would require an extension in the library's Worker classes which is probably not so big. A much more dirty approach may also be to use ThreadLocals... never worked with them. Paul On Jeudi, mars 28, 2002, at 06:33 , Chris Kay wrote: > Not sure if this ever came up before, but I was wondering if there is > any > way a registered RPC handler could find out from its WebServer the IP > address of the connecting client requesting RPC? > > I've looked through the code a bit and, apparently, in WebServer.java, > method run(), the Socket from serverSocket.accept() is retrieved which > should contain the client's IP address (method Socket.getInetAddress()). > However, the Socket is just passed on to the thread mechanism which, > eventually and ignoring any such information, will invoke a registered > handler's fitting RPC method, while the WebServer will be ready again to > accept other incoming requests. Obviously, the latter means storing the > IP > in the WebServer doesn't work as other requests might have come in > before a > finally invoked RPC method of a handler for a previous request queries > the > stored IP. > > Is there any way that the threads could carry on such information and > make > it somehow available to the handlers? Or better yet, am I just too > blind to > see the obvious, already working solution? :o) > > To sum up, it's the connecting client's IP that I am interested in, not > the > local WebServer's IP (which I assume can be queried from the stored > serverSocket if one extends the WebServer class). A solution where one > naively expects an RPC client to send its own IP as an argument with > the RPC > request is not desirable as it could easily be faked. > > Thanks for any help! > > Cheers, Chris > > > PS: My apologies if messages should not be posted to both mailing > lists. But > I just couldn't decide which of the two is the more suitable one. > >
