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.
Related
I have an SQLite Database on a webserver. I would like to access the database from a typical Java Desktop Application. Presently, I'm doing this thing...
Download the Database file to a local directory, perform the queries as necessary.
But, I'm unable to perform any update queries on this. How can I do this. [ On the actual database]
Another question is, to directly access the database from web in java (is this possible), make direct queries, updates anything etc,.
How can I achieve this type?
I've written code for connection of Java to SQLite and is working pretty fine, if the db file is in local directory. What changes or anything I have to do to establish a link to the file on webserver without having to download the database file.?
Thanks in advance...
CL. is right saying that if you need to access from desktop applications to a web database, SQLite is not an appropriate choice.
Using SQLite is fine in small web sites, applications where your data have to be accessed from and only from the web site itself; but if you need to access your data from - say - your desktop, without downloading the data file, you can't achieve that with SQLite and HTTP.
An appropriate choice for your web application would be MySQL or other client/server database, so that you could be able to connect to the database service from any place other than your web application, provided server access rules set permit that (e.g. firewalls, granted authentication, etc.).
In your usage scenario, you would be facing several orders of problems.
1) Security
You would be forced to violate the safety principle saying that database files must be protected from direct web exposure; in fact, to access your web SQLite database file from your desktop you would be forced to expose it directly, and this is wrong, as anyone would be able to download it and access your data, which by definition must be accessible just by you.
2) Updatability without downloading
Using HTTP to gain access to the database file can only lead to the requested resource download, because HTTP is a stateless protocol, so when you request GET or even POST access to the database, the web server would provide it to you in one solution, full stop.
In extreme synthesis, no chance to directly write back changes to the database file.
3) Updatability with downloading
You could download your file with a HTTP GET request, read data, make changes and the rest, but what if your online database changes in the meanwhile? Data consistency would be easily compromised.
There could be a way
If you give up using HTTP for your desktop application access to the database, then you could pick FTP (provided you have access credentials to the resource).
FTP lets you read data from and write data to files, so - on Linux - you could use FUSE to mount a remote FTP sharing and access it just like if it was connected to your local file system (see this article, for example).
In synthesis, you:
Create a mount point (i.e. a local directory) for FTP sharing
Use curlftpfs to link the remote FTP resource to your mount point
Access to this directory from your application as if it was a conventional directory
This way you could preserve security, keeping the database file from being exposed on the web, and you would be able to access it from your desktop application.
That said, please consider that concurrent access by several processes (desktop app + webserver instance) to a single database file could lead to problems (see this SO post to have an idea). Keep that in mind before architecting your solution.
Finally, in your usage scenario my suggestion is to program some server-side web service or REST interface that, under authentication, let you interact with the database file performing the key operations you need.
It is safe, reliable and "plastic" enough to let you do whatever you want.
EDIT:
MySQL is widely used for web sites or web applications, as it is fast, quite scalable and reasonably reliable. Activating MySQL server is a little bit OT on StackOverflow and quite long-winded to report, but in that case you could google around to find plenty of articles discussing such topic for your operating system of choice.
Then use MySQL JDBC driver to access the database from your Java desktop application.
If your idea is to stick with SQLite, though, you could basically prepare four web endpoints:
http://yourwebsite.com/select
http://yourwebsite.com/insert
http://yourwebsite.com/update
http://yourwebsite.com/delete
(Notice I specified "http", but you could consider moving to SSL encrypted http connection, a.k.a. "https", find details here and here. I don't know which webserver are you running, but still googling a little bit should point you to a good resource to properly configure https.)
Obviously you could add any endpoint you like for any kind of operation, even a more generic execute, but play my game just for a while.
Requests towards those endpoints are POST, and every endpoint receives proper parameters such as:
table name
fields
where clause
... and the like, but most important is security, so you have to remember 2 things:
1. Sign every request. You could achieve this defining a secret operation key (a string which is known to your client and you server but never travels in clear text), and using it in a hashing function to produce a digest which is sent together with other parameters as an incontrovertible proof for the server that that request it's receiving comes from a genuine source. This avoids you to send username and password in every request, which would introduce the problem of password encryption if you don't use https, and involves that the server has to be able to reconstruct the same signature for the same request using the same algorithm. (I flew over this thing at 400Mph, but the topic is too large to be correctly treated here. Anyways I hope this could point you in the right direction.)
2. Properly escape request parameters. "Sanitize" parameters someone calls it, and I think the metaphor is correct. Generally speaking this process involves some filtering operations performed by the server's endpoint, but it basically could be written as "use prepared statements for your queries". If you don't it could be likely that some malicious attacker injects SQL code in requests to exploit your server in some manner.
SQLite is an embedded database and assumes that the database file is directly accessible.
Your application is not an appropriate use of SQLite.
You should use a client/server database.
In any case, you should never make a database directly accessible on the internet;
the data should go through a web service.
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).
I am currently trying to transfer a file from a Android device to a Java TCP Server, but I am unable to find a good example which explains the structure I would need to implement this. There are many Java Client&Server examples there which explain file transfer but I want to make sure if this will still work once one throws an Android Device in there.
My question is how do I implement this sort of structure? And if it doesn't work, would I be better sending the file over an HTTP connection to a PHP server? I see a lot of examples and documentation online for the later method so I presume it is more reliable. I would however prefer to use a Java server.
The file consists of a large set of coordinates recorded by the Android device which will then be sent to the server. I have not yet established how I will store this data yet but I was originally going to store them in a primitive text file.
Design
The first thing you need is something to allow you to run Java code on your server.
There are a number of options. Two of the most popular technologies are Glassfish and Apache Tomcat.
Crudely speaking Apache Tomcat is sufficient for simple client-server communication and Glassfish is used if you need to do more complex stuff. Both allow Servlets (which are essentially self contained server classes written in Java) to run on the server-side.
They handle communication with the client by launching a JVM (Java Virtual Machine) each time they receive a request. The Java servlet can run inside the JVM and respond do some processing if required before sending a response back to the client.Each new request is run in a new instance of a servlet. This makes dealing with multiple concurrent requests simpler (no need for more complex threading).
Networking (sending data to and from the server)
In networking situations the client can be a PC, an Android phone, or any other device capable of connecting to the internet. As far as the server is concerned, if the client can communicate using HTTP (a standard protocol which it understands) the it doesn't care what sort of device it is. This means that solutions for PC desktop client-server applications are similar to one for a phone.
You can use library such as Apache HTTP Components to make it easier to handle HTTP requests and responses between the device and the server. Of course you could write your own classes to do this using Sockets but this would be very time consuming, particularly if you have never done it before.
Storage of Data
If you have time I would recommend implementing some sort of database to store the information.
They have a number of benefits to such as data recovery mechanisms, indexing for fast searching of data, ensure data integrity, better structuring of data and so on.
If you decide to use a database I recommend MySQL. It is a free and more importantly - well documented.
Aside: JDBC can be used to communicate with the database with Java.
Sorry about the in-line hyperlinks - apparently my repuation isn't high enough to post more than two!
Source: Personal experience from implementing a similar design.
Writing a simple multi client <-> server system in Corba.
I am stuck on unique identification of the client. Is there a mechanism in Corba, like some POA policy that would allow a unique user id to be generated by the server and carried along with all that clients communication.
Basically I have the system setup so I manually do this unique user ID. Client connects, server generates a key which is sent to the client and stored on both ends. A similar setup that you might employ in many environments. What I am asking is if Corba has its own mechanism for this that I can leverage.
CORBA doesn't have any inbuilt client ID mechanism that you can use, unfortunately. The main reason why CORBA never specified it is because it's difficult to define what a "client" really is: is it a process or a thread? Is it an entire tier or a single application instance? What about clients in the same process as the server? In addition, certain developers might want different behavior spanning any of those options.
Personally, I think that your approach of having the server dictate an ID for the client is fine, but keep in mind that it's basically a "session ID" approach, and that can be tough to scale horizontally. Make sure that you absolutely, positively need to ID your clients, because something as simple as client authentication via IIOP/TLS might not do the trick just fine.
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'.