This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
I am working on client/server architecture wherein I am using RMI to remotely access the server object. Here I call method(set and get method) on the object which will do database update or insert . Presently RMI does not provide authentication of client so any client who is able to get the stub can call the gettter and setter method. Therefore any client can modify my database. Can any one tell me how can I avoid this? Is there any way out to authenticate the client and ensure that only authenticated client calls the RMI Objects.
RMI over SSL? Require clients to "register" with a name and password before calling methods - check in other methods if the client has registered yet or not (using UnicastRemoteObject.getClientHost() to couple a client with a username/password...)?
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
Joined: Apr 10, 2006
Originally posted by Nathan Pruett: RMI over SSL? Require clients to "register" with a name and password before calling methods - check in other methods if the client has registered yet or not (using UnicastRemoteObject.getClientHost() to couple a client with a username/password...)?
Suppose i have my client software running on the client machine, and as the stub is downloaded on the cient from server, I can run another software which can even access the stub classes without though having RMI over SSL....Can you tell me how it can be prevented? Since once stub is available on the client machine, any other software can use it to ake a remote method call
Sorry - I couldn't understand some of your question...
How can "another software access stub classes"? It sounds like you are dynamically downloading stubs from the server - how is this "other" getting the stub classes?
"without though having RMI over SSL" does this mean that you aren't using RMI over SSL? Or that RMI over SSL isn't preventing "invalid" clients from making calls on the stubs?
"Since once stub is available on the client machine, any other software can use it to ake a remote method call" If you are dynamically downloading stubs from the server, the stub "class" should only exist inside the running JVM of the client that downloaded it - it shouldn't create an actual class file on the client or anything.
I tried to find some RMI authentification code with no success. So i made small library that allows to perform login/password authentification for rmi connections. It implemets a socket factory which sends and checks login and password on socket creation.