I wonder how can I use similar to Eclipse's remote debugging technique to get the data from remote object (that reside on server)? I am already have the client code and just want to extend it to bind (if possible) to some port and get the data from the server.
Honestly I don't want to use anything specific on the server side (i.e. create an additional code on server) because server already allows remote debugging and I can see the data in Eclipse debugger view.
If you can point me to some sample code - that would be even better. Greatly appreciate in advance.
Having read the #Romam's response to my comment, I think a better solution would be to add a simple server-side remote monitoring interface that responded to a client request, gathered the relevant object data, and returned it to the client. If the server side monitoring was compatible with JMX, you may not even need to implement any client code.
There are a number of problem with using JDPA for this, including:
Security: if the user can use your custom client to remote access your server, they can probably also use a regular remote debugger. That allows them to see any state they want to, and possibly remotely change state as well.
Complexity: driving the JDPA protocol from the client side is most likely not a simple thing to do.
Fragility: unless I'm very mistaken, your client will need to have hard-coded (e.g. in Strings) knowledge of class names, member names and member types for the server-side codebase. If you change implementation details of your server-side objects, your JDPA code may well break.
I suspect you'll find what you need here:
http://www.j2ee.me/j2se/1.3/docs/guide/jpda/architecture.html
And that you need to implement what if referred to as the 'front end' which 'implements the high-level Java Debug Interface'.
Related
I'm trying to protect my JavaFX code beyond that of ProGuard. I understand that any code that a user has in their possession is fair game. That means I need to move all my sensitive business logic onto a server which can be confidently protected.
Due to my limited server-side experience I'm looking for an explanation/example of how to develop the client-server connection so it's secure and reasonably fast. My main confusion relates to what is required in the client-side code such as server initialization and get/put requests(?), and also which files or code I put on the server (and where).
I've linked 3 quotes below from relevant answers to provide some background. The posts respectively are found here, here and here. The first one states:
we "protect" our software by having part of the
computation happening on the server side: we have several .class that
won't work unless they're generated from the server side and we send
them down the wire (and what is sent on the wire is always different:
we're generating unique, one-off .class files on the server side).
This suggests to generate entire class files on the server side. A few of my classes I'd want to fully have on the server, but many class files only contain methods which are sensitive and would need to be server based. The second link states:
Move the most critical parts of the service out of the app, and into a
web service, hidden behind a server side language like PHP. Move the
algorithm and have it process the data on a remote server, and use the
app to simply provide it with the data.
This seems more aligned with my intentions but I'm confused how to perform these "move" and "processing" functions. Do I simply replace the sensitive methods/class calls with get() requests to the server, which is behind a SSL connection provided by any basic server provider? Can you find a relevant full example?
Third quote:
Set up a server that responds to requests from your app, "uses" the
assets (whatever that might mean) and then sends the result back to
the app.
Once again, an example of how to "request", "use", and "send" entire methods/classes in a JavaFX context would be excellent. I'm willing to read all day, I just need guidance on this initial step so I start on the right foundation.
I need to secure the connection between my primary java app and my MYSQL server. Right now I have a class in my primary java app with the info about my SQL server (login details; user, password, schema etc).
I tried obfuscating that class but it didn't succeed. Then I heard something about calling an external java app with the connection info, and retrieve that info securely.
How can I execute such a thing?
Runtime run;
Process pr = null;
run = Runtime.getRuntime();
pr = run.exec("your program.jar");
pr.getInputStream().close();
InputStream eos = pr.getErrorStream();
and you can use a file to pass your info to the jar application
When dealing with a client/server style application, all the business logic, including the persistence layer, should be maintained on the server side.
That is, the client connects to some server process and makes requests. It should never care about how the data is managed or stored. It just cares about getting and manipulating the data. This also means that you centralise the business associated with that data, which means that should it change, you are less likely to need to change the client.
This also means that all the access information for the database never leaves the domain of the server.
Now the question is, how do you achieve. This answer will come down to exactly what it is you want to achieve an the means by which you want to achieve it, but, I would also add, the client should be authenticating with the server first, meaning that the user must be made to enter and user name and password in order to be able access the data (unless it's a public accessible API, then you probably don't care).
You could use
RMI. This would allow you to expose server objects that the client could interact with. This is good if you wish to send objects from the server to the client. It allows the client to interact with Java objects as if they were local objects.
From a coding point of view, this is a (relatively) simple solution, as you are dealing with Java Objects. The problem is though, only Java clients (with the right libraries) will be able to access the server.
You could use
Plain Sockets. This will allow you to connect to a service on the server and communicate with it.
You can even serialize objects between the client and server, allow the application to deal with Java Objects as well.
This is also a much more difficult approach, as you become responsible for dealing with the low level protocol and error handling (which RMI takes care of for you).
This approach does, however, provide you with the opportunity for other clients to connect to your server (so long as you are using just a plain sockets and serializing objects ;)).
This is a lot of work...
You could use
Some kind of web service (Servlet's under Tomcat for example or event a J2EE server), that would use simple HTTP requests to list of available services/functions that would return either something like JSON or XML response which the client would then need to parse.
This is, by far, the most open and probably the most common solution. It would take some work to get running, but is far less involved then using something like sockets and is also the most flexible, as you wouldn't need release no libraries each time you want to change or update a service.
Now all these allow you to provide secure connections over the wire, through SSL, you just need to establish the correct connection from the client to the server, so you've got an added level of security.
Each hides the database access behind a server layer, adding additional protection to the database.
I have to make an university project that involves a client/server architecture.
There should be a server where a client can login and search or save some stuff.
What's the best way to implement a stuff like that?
I think it can be done using RMI or ServerSockets or even WebServices, but what's the easiest way to implement this project?
Using Web Sevrvices i think it can be troublesome the authentication/session handling, using ServerSockets i have done some tests where i pass some custom serialized objects, but It doesnt seem to me a good way to go.
Any help is appreciated
Since this is a project for university I will not post an solution, but give you an good direction.
The most basic Way (what may be a good thing for a university project, and for understanding th whole matter...) would be with the Server listening in his Mainthread on a ServerSocket for Requests to connect to the Server and then for every (correct) Request (you need to specify somehow what is correct in this case) starting a new Thread with a Socket connected to the Client. This Threads should be hosted in some sort of List or whatever in the Mainthread of the Server...
Update:
So if this Server provides different functionalities to its clients, which are of course methods in our Server Code, you can specify the Objects which are crated when a new Client connects (I'm calling these "ClientServerConnection" from now on, and which run in its own Thread) in the Way that the Server Object is passed to it, so if one of the "ClientServerConnection"s get a Request for whatever they can call the matching method on the Server-Object and give an according response to the client...
Here some pseudo-code:
in Server:
//request for Connection came in
ClientServerConnection csc = new ClientServerConnection(this, "and everything you need, at least client IP for connecting the socket");
csc.run(); //running in its own thread, of cause ClientServerConnection should extend Thread
connectionList.add(csc); //a list of the connections the Server holds
in ClientServerConnection:
//A request to the use a functionality of the Server come in, in the easiest way you are sending a String, and than trying to match it here
if(recievedString=="doWhatever"){
Server server.doWhatever(); //calling the according method on the Server Object you passed by creation of the ClientServerConnection Object
//now return something to the client, according to whatever the Method did
}else if(recievedString=="doSomethingElse"){
//same again, according to whatever the now requested method does
}else{
//the client requested something you do not provide, need some sort of handling here
}
Hope I got you right and this helps...
'Easy' is a subjective thing, depending on what you already have experience on.
If you have experience in Java related technologies, you could pick a tech stack like Servlets, JSP and JQuery, and use GAE to keep things simple from the 'troublesome' aspects you mentioned. GAE is a platform as a service so you woudnt have to worry about those things, as google takes care of the authentication, scaling etc. You can use GAE with PHP too, if you are into that.
I think RMI is the easiest solution since you define all your interfaces and don't have to care about the protocol used to communicate.
You can also use web service with SOAP which is also a RPC (remote procedure call ) interface.
But by using Socket and ServerSocket you will learn how to build a server / client software from scratch, which is very important to know (because this is the basics).
Currently anybody can access the solr admin page by going to my_ip:8983/solr
I can't have it like that, so how can I make it prompt for password or something?
I have setup my servers apache2.conf file to prompt for password whenever my site is accessed by www.mydomain.com.
But when using another port, the "require password" wont show up.
Any ideas how to secure this?
Don't point me to the SolrSecurity wiki because it's simply too outdated. I have tried it without luck.
Thanks
Okay, this might be a bit long winded since the original poster doesn't know about network interfaces, so here we go...
Network interfaces
Computers which are connected to a network usually feature a concept of a network interface, which is an abstraction that combines IP configuration data (address, netmask, DNS servers, etc) to a hardware device that talks to the network (your ethernet card, your wifi card, whatever).
Additionally, you would have something called a loopback interface - a virtual interface that is something like your computer's ability to talk to itself :) Modern systems usually come with a loopback interface that is configured with an IP address of 127.0.0.1. This allows your computer to pretend to be networked even if it isn't, making some internal operations more generic.
Now, when you start a networked application, you usually need to tell it which interface to use, or in some applications' lingo "which address to bind to." Apache, for example, uses the listen directive for this. Go read up on it.
How interfaces relate to availabiliy
Let's say that your Apache server is listening on an interface which is configured with a public, Internet IP address... anyone in the world will be able to reach whatever that Apache is serving via the IP address, or via a DNS name which resolves to that addres...
That's generally what is currently happening to your solr instance.
Now, the important point about the loopback interface is that the stuff that is bound to the local interface is only reachable from that computer. I think you can see where we are going.
The solution
The solution would be as follows:
Configure solr to accept requests (or whatever it does) only via the loopback interface. You'll probably need to change some parameter such as "listen to," "bind" or something of the kind.
Configure Apache to reverse proxy the requests it receives on the public interface to solr.
Make Apache authorize requests by something like basic HTTP authentication.
If you are still stuck after this, ask on, and I can go into details, though I don't have any solr experience.
I am not an expert in this area. I only needed this for myself. In the web.xml of the app or of tomcat/conf/web.xml do what is described here:
http://www.alexxoid.com/blog/linux/restrict-access-tomcat-web-app.html
While doing this, I found the following links useful to set it up:
http://oreilly.com/java/archive/tomcat-tips.html
http://www.unidata.ucar.edu/projects/THREDDS/tech/reference/RestrictedAccess.html
http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
Tip: Instead of Proxy one can use mod_jk which should be faster
I have a situation where I want a Java client to have a two-way data channel with a servlet (I have control over both), so that either can begin data transferring without having to wait for the other to do something first, but to get through the firewalls this needs to be tunnelled in http or https.
I have looked around, but I do not believe I know the right terms for asking Google.
I was originally looking at http-tunneling modules, but realizing that I have a web container in the other end, I believe that the appropriate way is to think of a fat client needing to communicate home. I was thinking that the persistant connection in http 1.1 might be very useful here. I can easily do heartbeat transfers to keep the connection from ideling.
At this point in time I just need to do a proof of concept so I primarily need something that works now, which can then be optimized or even replaced later.
So, I'd appreciate pointers to projects that allow me to have a connection where either side can at will push information (like a serialized object or a descriptive stream of bytes) to the other side. I'd prefer pure Java, if at all possible.
EDIT: Thanks for the pointers. It appears that what I need, will be available in the servlet 3.0 specification, which I might end up using in the long term depending on when it will be supported in the various web containers.
For now I am investigating the Cometd package, which appears to be able to do exactly what I need for my prototype.
Search terms: comet, long-polling
These are mostly used in an AJAX context, but I see no reason why you could not use them in a Java project.
Please take a look at Eclipse Net4J,
http://wiki.eclipse.org/Net4j
It supports all the features you mentioned. A special nice feature is that it supports HTTP connection pooling so you can have lots of channels between client and server but use only a few HTTP connections.
The only problem is that it doesn't have documentation at all. You just have to read the source code. Once you figure it out, it's very easy to use.
There are a few more diagrams on old Net4J site,
http://net4j.berlios.de/
How fast does it need to be? You could always just do polling on the client. Just check for new messages every so often.
You can use the Hessian protocol over HTTP. It's a fast binary protocol for serializing data. Typically used for a web-services style RPC communication, but there's no reason it couldn't be 2-way - see Hessian mux. It's pure Java, too :-)
Generally this is done by having the server not respond to an http request immediately. It waits around for some update (or a timeout) before sending a response. Obviously some care needs to be made ensuring that the server will handle this under load.
See, for instance, Comet.