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.
Related
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.
Is it possible to hide database details in jnlp-file? My app use jws and MySQL-database. In jnlp-file i have defined db connection details (username, pw, hostname).
Like this:
property name="dbuser" value="username"
Is there any alternative ways to define database details? Details must be easy to change!
Look at the JnlpDownloadServlet Guide: Substitutions.
JnlpDownloadServlet makes convenient substitutions in your JNLP files. When the client requests a JNLP file, the servlet reads the original file, substitutes values, and returns the results.
Is it possible to hide database details in jnlp-file?
No. Not to a power user.
The app probably shouldn't be talking directly to the database unless you trust all your users. Instead, you should hide your database behind a service, for example a REST service.
Never trust the client. The user can modify your program to do what they want and they can read anything you store on their system or anything sent over the network. Even if you use encryption, if it is decrypted on their computer then they can read it.
It is not a good idea to hide a secret on someone's computer and hope they don't see it. Even less so when your program is frequently reading this secret, making its location obvious.
You should assume that somewhere you have a hostile user who has modified your program (that runs on their computer) to do their bidding, and they know all the information you send to their computer.
You could create a database user for each of your users and still let them connect directly to your database, where their database user has very limited access. I think this would also be a bad idea. Databases often don't have the best security.
Instead, firewall off your database and only let your internal systems access it directly. Your users (through your java app) can instead access a web service like Chris suggested. This gives you a much smaller attack surface, which is easier to secure.
I have a Java application that sends user score to the mysql table. When the user is done, Java app accesses the .php file on server and the .php server performs a query on the database (inserting score).
I am concerned about the (in)security of this method. I mean, if someone finds out the direct url to the .php on a server, they can produce a lot of mess in the dabase. Can you advise how I could prevent the .php from executing the query other than accessed by the Java app?
edit: The problem is that Java application is NOT run on the server, it's run on the user computer using Java Web Launcher platform. So it's not an applet...
The problem is conceptual. You should never be sure that users can't find out the real address (security by obscurity). You could use SSL, still this is no means against a good guess.
Since the Java program is run on the client side, a .htaccess restricting access to a certain IP is also not an option.
My suggestion is to create a separate user in mysql, grant this user access only to necessary tables and perform the database queries on behalf of this user directly in Java. This way all data is encrypted (see http://dev.mysql.com/doc/refman/5.5/en/ssl-connections.html) and no URL/access point is exposed. Of course it means your MySQL server must be reachable from outside which poses a risk, too. You should have a good root password!
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.
Our customer has a client/server application based on mdb database (microsoft access) and he'd like to expose part of data via his web site (deployed in java).
What is the best way to achieve it?
I need a place to start (for example web service, spring integration, mule, service mix).
If the web server is currently located on your office LAN, and the access front end applications can use/see the folder where the back end mdb file resides (we're talking windows networking here), then in theory you could expose some of this data to the web server if web server loads and usage rates are not going to be too high.
In the case that the server is not going to be on the same Office Network, then an often used an reasonable solution is to simply move the back end data out of access and move it into some database server such as SQL server, or mySQL. When you do this, then both the access application (front end part) thus continue to run and function as before. And now also the web site can also share that data. This so called upsizing process of access data is not hard to do, but you want a competent access developer that knows both SQL server and access, and has done upsize many times. If the developer done this many times then it not a lot of work in most cases to move the data out to a server and keep the existing code investment.
So your choices are to keep the access code and database as is, but simply move the data out of access to a server based system. As noted the other alternative is in the case that if your web server is attached to the same network where access data resides, then in theory would be a simple matter to place the access backend data on the same server as the web server. This setup would allow both the locally users on the Office Network, and the web server to share and utilize the data in the access backend file.
Another alternative is of course is to have access to connect to a database server your utilizing on the web system, such as MySQL of SQL server. Since access can connect to the database server in this fashion, then again it is theory possible to shuffle data at predetermined times, or even during use to pull data down that's been gathered from the web site into the access application. So you keep Access as is, but connect it to the web part that gathers needed data.
Which of the alternative above choices above makes sense will depend on your particular set of circumstances.
To really throw a wrench into this mix, access for 2010 can build scalable cloud computing systems where the data is based either on Azure SQL or even 100% web based if you have SharePoint. In fact when you publish an access database to sharepoint now the result is .net XAML (zammel) forms and a scalable system in terms of users. In the following video you'll say that the halfway point I switch to running the access application entirely in a browser:
http://www.youtube.com/watch?v=AU4mH0jPntI
To do the above access web development, you'll be using SharePoint. However, if your organization does have SharePoint now then this could be a reasonable possibility for you.
You can connect to your ACCESS database with Java through JDBC-ODBC Bridge.
The steps to do this would be:
In your server (the one hosting your Java Web Application) create an ODBC entry pointing to your ACCESS file. Name it mdbodbcaccess.
Then connect to that ODBC entry from Java using JDBC.
Something like this:
//
// points to the entry you've just created
//
Connection conn = DriverManager.getConnection("jdbc:odbc:mdbodbcaccess");
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery("select f1, f2 from table");
while (rs.next()) {
// iterate your resultset and do something with it
System.out.println(rs.getString("f1"));
}
rs.close();
st.close();
conn.close();
Alternatively, you might want to use pooled connections from your Application Server.
I believe that you are a little bit disappointed.
MDB is Message Driven Bean. It is not database. It is a way to listen to JMS destination and perform some action driven by JMS messages. The data already must be saved somewhere in DB. If they use MDB it is a Java EE application.
Now about the site. Which technologies are used for site? If it is java based technologies your life is easier because the site is a Java EE application too. In this case you actually have 2 Java EE applications. If all these correct you can
merge them. In this case you can just call the "mdb based application" from the back end of the web site.
Alternatively you can call one application from another. Perform remote EJB call or expose some of the API as a web service and call it. Or even connect to the queue of "mdb application" from site and send messages.
If site is not written in Java use web services or connect to queue.
Generally you have a lot of possibilities. But it is hard to recommend something specific without additional details. I hope that this answer helped you a little bit. If you need more help please provided details.