I have a javafx app that i created and it makes calls to the mysql database. Unfortunately the database username and password is viewable if you view the jar files. Is there a way to have the javafx app connect to a PHP file on my web host server to manage these database calls and database connection so I do not need to store the creds client side? Or is there a better way to handle this server side? Maybe an API?
Uploaded picture of what I mean
The first thing you should determine is the data that you want to read/write using your java application. Only that data that it needs.
The second is why do you beware of revealing storage access credentials? Is it because of data that shouldn't be visible from the java application?
If an application has access to data hance the owner of the application has access to data. No other options here. The only thing you can do here is to restrict access for each application to its data. It means that each application should have its own credentials which give access to that application's data.
It doesn't matter if you use either MySQL direct connection or API. In both cases, you have some access credentials (DB login+password or API token) or don't have credentials at all but the last one means everyone will have access.
I have a central SQL server which can be INSERTED INTO and SELECTED from via PHP. However I have built a Java application which I hope to be able to Insert and select stuff in the SQL table with that I have hosted on a web server.
How would I go about doing this? I don't really want to have the root password with JDBC in the source code as even if it is obfuscating it can easily be deobfuscated and then the user has direct access to the database.
Someone said to me that I should use an API but I don't see how I will be able to interact with the database by doing this.
If you already have a PHP application running server side that handles database interaction; I recommend letting that handle if for you.
Write an API in PHP that handles all of the database interactions and send requests to that API from your java application. (I'd probably have the users create an authorization token to pass along to the API as well so you can track who is using your API and limit access).
Your application can then send HTTP(s) POST/GET/etc requests to your PHP that will then handle the database interactions and return the results. Your database username and password will be kept on your server and your application will not need to know them.
If you don't want to rely on a backend service and want your client application to interact directly with the database... You'll probably have to include a username and password in the code. BUT I'd create a separate user in the database with limited accessibility that could be removed anytime you suspect abuse.
I have have a BIG problem in the past few days. I'm developing an application for a customer and I have an external database in the web. In the program there are a login and some modules. At the time I store the data for access to the DB hardcoded in the Java code. Of course this is not a way to store those data.
Then I was searching so much to find out a way to connect to the database.
Store the password in a properties (.xml) file on the PC
Encrypt the password
etc.
But all of this is not really secure. Then I found something good. "Three-Tier Application Server" sounds really good and a possible way that I don't have to save the data on the PC. But I read everytime how a Three-Tier server works, but nowhere how to develop something like this in java. And is there a possibility that a hacker write an application that connects to this server too and get all of the data, because he decompile the application and get the access data?
Thanks for help
There are indeed many ways you can go about this.
The best way is to have the authentication checks spread throughout your code to where it would be very hard to remove them.
Have the authentication with SHA256/512 and or MD5 and have the user send a login request to the server.
Only authenticate the user if the server responds that it is registered.
Do not store any information other than the users info on the client end.
All the checks should be made and validated on the server side.
You also most definitely want to obfuscate your client sided code as well.
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 am writing an application in java and i want to enable it to access a mysql remote server.
my problem is that if the application have the user name and password someone can take them and use my db with a different software.
is there a way of preventing it ?
UPDATE
i found this workaround for connecting to a remote MySQL database from an android device.
you put a service in the middle. like a php page that code the data in JSON format which the android app gets via http.
here is the example i found :
Connecting to MySQL database
Having the username and password is designed specifically to grant access to the database. That's the whole point.
You could go to some extra lengths like restricting database connectivity to specific hosts, so at least your paying customers get access to the database and no else can access it, but your customers might choose to use different software to access the database. There's no way around it except licensing terms.
What you could do is run an intermediary program on your own hardware that connects to the database and restrict access to the database to software that is under your direct administrative control. Your program would validate all requests from software under control of your customers and allow the queries that you want to allow and refuse (and log) the queries you do not have to allow. (You do not need to send raw SQL data back and forth -- you can do any amount of processing on the data and queries.)
You can setup JDBC Data Source on your application server. Here you can see example for Oracle Glassfish.
So, your credential won't be used in your code/resources.
If you are saying that you have an application trying to access a MySQL remotely (not in the same box), then i think you need not worry, as the connection that will be established by your application codes will not expose the username and password when it is trying to authenticate and authorize itself to the MySQL server.
You can limit the access to the MySQL-server so that only certain IP-addresses or IP-ranges have access to it.
As a side note, make sure that the user you use in your application only has the needed permissions to the database. For example, the user might not need to be able to create or delete tables. You can even specify permissions for the user on table and column level.