I'm using GWT for a web-app and I need to access to a mySql-database. There will be only one client (The app is used on a iPad localy). Is there any way to access the database without RPC? I'm looking for a possibility to direkty query a database.
Thanks!
There are 2.5 reasons you cannot use gwt to directly access MySQL.
Reason #1.
GWT is compiled into Javascript. You need to open a socket to the database server. GWT does not allow you to open a socket. In fact, no unaugmented browser (before advent of html5) is able to open a socket. But you can open a socket using Flash actionscript, or HTML 5 javascript.
Reason #2.
OK, let's say you used HTML5 sockets. And you spent 6 months writing in Javascript a JDBC connectivity. But, your websocket would still need to address a servlet on the server which would help your websocket establish a persistent connection - and mysql is unable to perform such an establishment.
Reason #3.
SLD - SOP restriction:
(Second Level Domain Same Origin Policy)
Standard browser restricts its pages to only be able to request for, and to include, content from within the same second-level domain (SLD) as the server that provided that page to the browser. Top level domains (and top-level and a half) are such as .com, .org, .net, .me.us or .co.uk. So, domain names such as google.com, fbi.gov, mit.edu are second level domains. While, mail.google.com would be a third-level domain. Therefore, GWT would work only within the confines of an SLD. Your web server must also be accessible at the same SLD as your mysql server.
SLD-SOP and tunneling requirement is to close a security hole that could have allowed any tom-rick-or-mary to log into your system thro your browser. Tunneling is always required for a browser to connect to a server other than a http server. Tunneling is when a browser exploits the web server as a yenta (yiddish for busy-body/go-between/match-maker) to get to another server.
You have no choice but to use GWT-RPC. Perhaps you don't wish to use RPC, then you could use RequestBuilder, or Script-Include or RequestFactory. But they are all still diverse means of tunneling. http://h2g2java.blessedgeek.com/2011/06/gwt-requestbuilder-vs-rpc-vs-script.html.
There is one reason why you can connect to your database server from your gwt client:
Your database server must run httpd connection engine. That is, your gwt app would access the db server thro http. I am not familiar with which relational database has a http access available. Most probably, you would have to query thro xml or json.
However, a company I had worked for created our own http service to allow "direct" client access. "direct" is a misnomer because we used tomcat. It is stil tunneling. Any database company that offers "direct" http access is still tunneling. Tunneling - no escape from it.
You could augment the browser with Flash and write a Flash application rather than using GWT. If direct access is so essential to you, you would have to abandon GWT and develop in Flash and run a httpd engine for your database server.
GWT is ultimately Javascript. As noted at Are there JavaScript bindings for MySQL?
, there is currently no way of accessing MySQL from Javascript.
Therefore you can't access it from client-side GWT code.
AFAIK it's not possible, and even if it were, it would be a really bad idea. Are you sure you actually need a database? Maybe something like gwt-client-storage would be more appropriate.
EDIT
Your database would we publicly accessible and open for any sort of attacks.
EDIT 2
This may even be a better solution, as it offers support for accessing the HTML5 Database API and is targeted to iPhone/iPad.
gwt-mobile-webkit
If you were even successful in doing so, in short, doing a CTRL + U on the browser would make your database name, username, password, tables names etc visible... And done, any developer curious to know your code has a way to hack anything and everything in your server.
I think it's not possible, I mean, if you want all your data stored in DBs. I mean, GWT compiles into javascript and javascript executes on the client (typically a web browser).
If you want to access data stored somewhere (by some mean) in a server, then you have no option but RPC. If I were you, I would stop thinking in client-server paradigm (GWT was developed with that in mind). Perhaps some embedded database like H2 and then hold connections through JDBC.
Related
I am creating 3 applications that are written for different platforms (.NET (C#), Android (Java) and PHP). I'm using C# for the WPF application that is going to run on Windows PCs, PHP on the server side and Java for the mobile app. I am using a MySQL database where I'm storing all the information that 3 apps are going to be using.
I am using web requests to my Apache server (JSON and POST basically) when I need some specific stuff to do with PHP.
But, how safe is:
When I'm connecting to the MySQL database via C# and Java?
When I'm sending GET and POST web requests with C# and Java?
Can you somehow spy on the traffic that is going on between the device (PC / Android device) and the server and find out the user and the password of the database, or even get the post request parameters that the app is sending?
Because I know there are a lot of network-monitoring software and I wouldn't be surprised if this is possible.
If it is, then how to avoid it?
"How secure are Java and C#?" isn't quite the right question, because the answer depends on what you do rather than the features in the languages. They both have plenty of good options for implementing various types of security in various ways. What really matters in your case is how the machines communicate.
Can you somehow spy on the traffic that is going on between the device (PC / Android device) and the server and find out the user and the password of the database
Your clients (the PCs and Android devices) should not be connecting directly to your database. They should submit requests to your server, where you have much more control, and can authenticate clients and validate their data. The server then connects to the DB.
If the clients call the DB directly, not only are the credentials transmitted over the internet, but they must also be present locally on the client in some form. This means that someone could potentially crack your app and get access to them.
or even get the post request parameters that the app is sending?
Yes, these can be intercepted and read. Again, preventing this is a matter of how you implement the communication. Use the HTTPS protocol, which you can do in both C# and Java, and the content of your requests will be protected from being intercepted by third parties along the way.
When your traffic is noticed or intercepted it will be freely interpretatable to the reader. You can see an example of such traffic in the console window of your browser, or if you want to view the actual application traffic use a proxy (such as Fiddler2).
If you want to prevent your traffic from being read, you have to take measures to ensure authorization and access control. You can do this by encrypting the traffic with TLS/SSL. If you have web-endpoints you can often enable https trough the libraries configuration. You may need to pass it as a parameter to the code that builds your connection.
Furthermore, it is best practice not to divulge sensitive information in your application output. You will want to use strong passwords and refrain from storing or sending these in plaintext.
I would also advice you to break down the need for securing in smaller bits.
Example:
You are using a lot of different technologies. These all have best practices and guidelines related to security. Separate your applications from your networking/operational assets. Encrypting your communication is a measure in your application. Whereas your MySQL configuration works in a different way entirely, mostly trough configuration.
Why are you connecting directly to your DB from the Android/WPF apps?
If the MySQL DB is sitting on a secure server, perhaps wrap the database calls/services in RESTful APIs implemented in your PHP solution, then call the APIs from your client apps, this also saves you from writing SQL statements and DB specific tasks in multiple languages (Java/C#)
not knowing your situation makes it hard though...
I have a JavaScript embedded in a website, running in a normal browser, and I have a Java Application running on the same machine. I am looking for a way have both communicate with each other.
I assume that creating files in the local file system from inside JavaScript running in a browser is out of question.
The only way I came up with would be to use a server that both programs can send messages to, and from which they poll for new messages.
Is there any other other way to accomplish this?
A couple of ways I saw in practice:
You Java Application may listen to some local port which your JS will access for instance via XHR. You'll need to mind cross-site scripting (your JS may need to be loaded from that local URL), but this is doable. The easiest would probably be to run an embedded HTTP server.
Your Java Application may be registered as a protocoll handler in the OS. Then JS would open links registered with the application thus sending data to it.
As #PavelHoral is pointing out, CORS is a way to workaround same-origin policy.
JavaScript inside a browser can only make AJAX requests or communicate with browser plugins if they provide some additional JS interface.
Local HTTP connection
One option is to listen for HTTP connections in your Java application (does not have to be servlet).
You will need to handle CORS correctly.
Central server
Other option is to have a central server to which both your JS and Java code will connect.
Java applet
Another option is to have Java applet. When running in privileged mode you can do pretty much anything (maybe you can convert your Java application to Java applet).
You will need to handle applet security here (e.g. signing applet with trusted certificate).
Please refer to this question for direct sockets communications from within javascript. You'll need a HTML5 browser, and likely this won't "just" work or necessarily be a good idea if you want to publish this on the WWW.
How to Use Sockets in JavaScript\HTML?
I need to connect to a MySQL database from a java Desktop application. The way I was planning on doing this, was using HTTP to open a php page on my website, that PHP script will handle all the mysql stuff so my MySQL user/pass is not accessable to the client at all. so, my question is, would SSL be required? and also, how could I prevent people from taking the URL to the PHP script and using their web browser to mess things up on the database?
This should probably be on the security site, but anyway.
If you don't want everything you send to the database to be visible to the world, use SSL.
Force the client to authenticate to your server side script before making any changes to the database if you don't want anyone in the world making changes.
Make sure that SQL injection is prevented.
Why wouldn't you just use MySQL user authentication with SSL? Writing your own bridge sounds like it would only cause problems and expose more security holes than you'd otherwise have.
so, my question is, would SSL be required?
SSL helps provide a layer of security, through encryption, which keeps people from hijacking the connection and intercepting what you send (for more information, see: Firesheep). Therefore, while not required, per se, it is recommended. If you have control over the Java app, and depending on your purposes (namely, an in-house application), then you can use a self-signed certificate and package the cert with the app for verification purposes (see: this SO question for more info on self-signed vs CA SSL certs).
how could I prevent people from taking the URL to the PHP script and using their web browser to mess things up on the database?
As with other Information Security things, nothing is 100% guaranteed, but the most common way to do this would be via an API key, especially since what you're describing is an API.
If you're looking for a quick-and-dirty setup, then you can use HTTP Basic Authentication to send some credentials, and use SSL to secure it. For a more robust solution, you'll probably want to look into HTTP Digest Authentication and/or OAuth. What you use will also depend on your specific needs.
You can then code the API key into the Java app, or create a way of generating and requesting API keys (again, depends on your specific purposes and needs), and the client sends the API key with the request. If the key doesn't match what you have "on file", then you deny the request.
A quick note on using an API vs connecting to MySQL directly
A couple of people brought up connecting to MySQL directly. I think this is a valid option, but will depend largely on what you're doing and who you're distributing to (and, for that matter, whether you want to open that database to other clients).
If you have plans to have other clients (such as mobile devices) connecting to this database, or if you don't have control of the database for whatever reason (ie - your hosting setup won't allow you to make remote access available), then it might prove useful in the long run to build an API.
However, if you have no such plans, or do have full control of the database, and you control the source code of the Java application, then directly connecting to the MySQL database is a valid option. Just make sure you follow the principle of least access - the Java application gets a dedicated MySQL user that only has the permissions that are absolutely necessary - and the Java application user has a strong password (and since no humans are involved in this process after you code it, you can use a password generator to create something long and convoluted and completely random).
I would like to create a touch screen application.It will be a windows application, so using that how can i get data from a web server?
There are several methods.
Your server can create scripts/webpages to return data in XML or JSON format upon request, and your windows application will have to make HTTP requests to your scripts/web server, retrieve and parse to get the data.
Make sure to protect your data which are requested from the web to prevent other unintended use.
You can also directly connect to the database (depending whether your database supports remote connection or not...)
Using a webserver is usually totally independent from the clients operating system. It may be tricky if the webserver provides service and entity beans and you rich client is written in C/C++ language.
But there are several protocols where you do not have to care. If your application is a thin client (browser interface), I suggest having a look at REST. For rich clients you can use SOAP to talk with your server.
Of course, the server has to provide the data for the chosen protocol...
I've got a Java client that needs to access a remote database. It is the goal to hide database credentials from the user and not hardcode any credentials within the code. Therefore, the database access will probably have to be on the server side.
I'm restricted to use Ibatis as a data abstraction framework. Apart from that I have JBoss running on the webserver, allowing me to use data sources.
How would you design the remote database access and data serialization/deserialization. would you prefer web services of some kind of data stream over a socket? How would you realize either of both?
Build a Service Layer and expose it over RMI - possibly as EJB3 stateless session beans as you have JBoss, possibly as pure RMI. I wouldn't bother with web services unless you have a specific need. RMI will take case of serialisation for you.
Your service layer needs to expose a method to authenticate users using their credentials entered on startup of the Swing app. All calls for data go through the service layer. No SQL exists in the Swing app.
There are other benfits of this arrangment other than just hiding the database credentials. Not only do you end up with a layered architecture, but you gain efficiencies from sharing prepared statements amongst all your clients by having a single data source on the server.
So you want users to be able to access the database without knowing the credentials? Your only option is server-side database access. Unfortunately there is no way of hiding the username and password in Java -- if you put it into a properties file and encrypt it, a determined attacker could still attach a debugger and see what values are being held in your code.
Also, unless you're connecting to the DB over a secure connection someone could run a packet sniffer such as tcpdump and get the credentials there.
You say that you're running a JBoss server, what might be best is to set up remote EJBs so that your client application doesn't access the database directly - it has to go via your EJB methods. (It doesn't have to be EJB, by the way, you could do something such as web services if you prefer).
The point is, your server talks to the databas directly, and your client's only access is via a limited set of interfaces you define on the server.
As has been already said, you have to connect to a server which handles the database connection. There is no way to effectively prevent someone from breaking your security, with 30 minutes of effort.
If the clients are connecting somewhat locally, within an intranet, using EJB's on your appserver is probably the best choice... though you probably want stateless session beans, i wouldnt necessarily discount message driven beans.
For longer distances where the traffic is coming from the outside, I would use webservices over HTTPS
In any event, most appservers have mechanisms to expose their EJB's as webservices, with the WSDL; and there are about a hundred utilities to generate clients, to call the webservice, from a WSDL (axis's wsdl2java works well enough)