I've recently gotten my hobby java project embedded into a page thanks to this very site, but now I'm having some security issues.
I have the include:
import java.sql.*;
and the line:
Class.forName("com.mysql.jdbc.Driver").newInstance();
as well as a mysql .jar file in my src directory, it works from the console, and in the applet works fine from the applet - up until that forName() line in my code, where it throws the exception:
Exception: com.mysql.jdbc.Driverjava.lang.ClassNotFoundException: com.mysql.jdbc.Driver
java.security.AccessControlException: access denied (java.lang.RuntimePermission exitVM.-1)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkExit(Unknown Source)
at java.lang.Runtime.exit(Unknown Source)
at java.lang.System.exit(Unknown Source)
at applet.Database.connectDB(Database.java:80)
etc...
I think I may be able to fix it with a client.policy file, otherwise I might need to write an abstraction layer which uses a server-client network connection to query from the server-side...
I'm sure the Java gurus here probably know the best way about it.
I think the security exception is actually from a System.exit() call in your applet, after the Class.forName(). Generally you are not allowed to call System.exit() in unsigned applets as it shuts the whole JVM down. Have you checked if line 80 is actually the Class.forName() line, or does line 80 have some kind of exception handler which tries to call System.exit() if the driver does not load?
Anyway, in order to load the mysql jar file in your applet, you need to include it in an ARCHIVE attribute like this:
<APPLET ARCHIVE="mysql.jar" CODEBASE="./src/" ...
Once you get past this stage, you will still need to host the mysql server at the same IP number/hostname as the webserver, and open it to all the same people who can access your applet. As Tony said, this isn't how people normally do it, for security reasons. Better to write something on the server side, if you have control of the app server, and use XML or some other data exchange method to get the data out to the applet. Of course if you are just experimenting to learn about applets, then it's probably fine - but do take care to keep mysql behind your firewall if possible.
If you're trying to use the a JDBC driver from the applet, then the applet needs to be signed with a certificate, and your server needs to deliver this certificate when the applet is loaded on the client side.
The accepted way to do this is to make HTTP requests for data from the server from which the applet was loaded, and run the queries from the server. JSON or XML are good ways to exchange data between the applet and the server (similar to the way you do an AJAX application, sending XML or JSON between the browser and the server).
As mentioned in one of the other answers (#Leigh Caldwell), I would strongly recommend not doing things this way. If your applet has access to MySQL then so does everyone else in the world. Decompilation is so trivial these days that it would only be a moment's work for an industrious hacker to get the applet credentials to the database. Also, MySQL's user/pass authentication is fairly weak, most of its security is IP-based. By opening it up to the world, you're throwing away your first line of deference.
A better approach would be to build some sort of frontend protocol on the server side (XMLRPC would be a good foundation and easy to use). If the applet absolutely needs access to a database, your best bet would be HSQLDB in memory. This doesn't require any file permissions and can be run completely in-sandbox. The local in memory database could be synchronized with the server as necessary using the aforementioned XMLRPC facade.
Try getting rid of the newInstance() part. I think just having the Class.forName() does it for loading the driver.
The exception tells you that the applet has been unable to load the driver class. Your applet needs to download the jar containing the class at runtime, via HTTP, so you must have the jar (mysql.jar or whatever it is called) available on the webserver.
Once you solve this problem the user will have to allow the applet permissions so that it can make a TCP socket connection to the mysql db server. They will prompted with a dialog box...
Related
Sir/Madam,
I have design an application using java-applet in that i want to save pdf file on server location i.e http://www.mywebsite/myfolder/ . On local side it will run successfuly but actualy on server side it will not work.
As far as I understand, you would like the applet to store the file on the server. That is obviously not possible because the applet runs on the client. The option I can think of, is to implement an HTTP Post from the applet to the server and handle it on the server.
Short answer: applets run on client side so they save nothing on server.
Longer answer: that applet will have to communicate somehow with a server side-application. I.e. like this SO Q&A.
A question on tech stack: Is it really necessary to use applet? It's obsolete technology. Can't you use a jnlp rich client application? Or a simple webapp?
It seems that with the latest Java update, 1.7.0u45, my JNLP application that is supposed to connect to a server is instead forced to try and connect to localhost for some reason that I cannot quite seem to figure out.
I know that some other changes have been made, such as requiring the Permissions attribute in the manifest and some such things, which I'm currently trying to figure out a reasonable way to comply to, but I cannot find anything that ought to cause this behavior.
My code just does an ordinary Socket.connect call to a specific server, but what happens is that the connection is instead made to localhost. This only happens when the code is running in the JNLP client; not when I run it "manually" by starting the VM on it.
Does anyone know why this is?
At last, I managed to figure out what was happening. It was not, in fact, that connections as such were being redirected, but rather that the JNLP client has started blocking JNLP files that are not signed from setting system properties with certain names. Particularly, only properties whose names begin with jnlp are, it seems, guaranteed to be configurable by unsigned JNLP files.
The problem, therefore, was that I specified what server to connect to via a system property whose name did not begin with jnlp, and it then being blocked (since my JNLP file isn't signed) led to my program using its default server specification instead, being localhost.
I have embedded a JSCH SSH Java applet in a web page and need to know if it's possible to run a script (of any language like PHP) to automate logging in and running commands. I have heard of expect4j and java robot but cannot see any way to implement it. Keep in mind, I'm not great with Java so I don't know everything about it. Any help is appreciated.
JSch is an SSH client library, and by itself only allows programmatically steered connections to another server. The user interaction has to be build around it by users of the library.
The JCTerm applet provided on the website also contains a terminal emulator in form of a Java GUI. If you only want to automatically execute some command (and maybe show its output in the web page), you could do everything on the server side, and don't need the applet with its terminal emulator. (You would need either some PHP-Java bridge on the server side or some Java-enabled webserver with a Servlet or similar, though.)
(If the web server would be the same machine as the server you'll run the command on you wouldn't even need the SSH connection, but could execute the stuff directly.)
If the server can't do anything (i.e. a "static server"), an applet is the way to go, yes. You can either modify JCTerm or create a new applet from scratch (using JCTerm's connection code as an example on how to connect to to the server).
If you don't have to fear any malicious users in your LAN (i.e. between web server and user, the SSH server doesn't matter), you can embedd the password (or preferably a private key for public-key authentication) into the applet's jar file, and pass it to the library for connection. (You should also include the server's public key for easier checking.)
Provide the command(s) to a ChannelExec (instead of a ChannelShell), this makes it easier to provide input (if necessary) and capture the output. Pipe the output in a text area, or simply use a green/red label saying if the command was successfully executed.
(I might have a look at this in the next days and try to do it. No promise, though.)
Actually Iam writing a plugin for an java app that comes in two flavours 1.)as executable and 2.) can be launched from a webpage as an applet.
At some point I needed a custom form that displays various data from an oracle database. I build that form and the class that does the jdbc query needed.
Now when it comes to the executable the form pops up correctly with the expected results, but when I try to call it from the applet it launches with all fields empty and no error whats so ever.
The only thing I can think of is that due to the asychronous nature of the web, the form pops up before the query returns the result.
If that is true, is there a workaround?
I believe that you just catch exceptions and therefore do not see them. Or just do not know where to search for them. Did you open applet console? I believe that you will find some exception there.
Applet is not different from application. Applet just has security restrictions. It cannot perform TCP connection to server other than one it was downloaded from. And important: the security check is pretty stupid. It is based on string comparison. It just compares host names of applet base and the host name of host where you want to connect. If for example your host name is myhost.mycompany.com and its IP is 200.201.202.203 you have to use either DNS name or IP address in both places even if ping of DNS name returns your IP adderess. Check this and I hope everything will work.
BTW, do you probably know that you are using "old", "obsolete" design? This is the beginning of 90s design. People switched to N-tier architecture ~12 years ago, so, to improve your solution you should implement DB access on server side and talk to server via some kind of protocol, e.g. rest API.
I have an applet that throws this exception when trying to communicate with the server (running on localhost). This problem is limited to Applets only - a POJO client is able to communicate with the exact same server without any problem.
Exception in thread "AWT-EventQueue-1" java.security.AccessControlException: access denied (java.net
.SocketPermission 127.0.0.1:9999 connect,resolve)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
My applet.policy file's contents is:
grant {
permission java.security.AllPermission;
};
My question is what are the other places where I need to modify my security settings to grant an Applet more security settings?
Thank you.
EDIT: Further investigation has lead me to find that this problem only occurs on some machines - but not others. So it could be a machine level (global) setting that is causing this, rather than a application-specific setting such as the one in the applet.policy file.
EDIT: Another SO question: Socket connection to originating server of an unsigned Java applet
This seems to describe the exact same problem, and Tom Hawtin - tackline 's answer provides the reason why (a security patch released that disallows applets from connecting to localhost). Bearing this in mind, how do I grant the applet the security settings such that in can indeed run on my machine. Also why does it run as-is on other machines but not mine?
Seeing this: http://sunsolve.sun.com/search/document.do?assetkey=1-66-246387-1, it's clear that Applets run from localhost (without being deployed to a web server) cannot access localhost.
There is no workaround for this issue as indicated
4. Workaround
There is no workaround for this issue.
Please see the Resolution section
below.
My suggestion is as follows:
Signing a Jar file to get more security privileges (http://java.sun.com/docs/books/tutorial/deployment/jar/signindex.html)
It stipulates:
Users who verify your signature can
grant your JAR-bundled software
security privileges that it wouldn't
ordinarily have.
Running your applet from a web server (such as Tomcat) and accessing it locally through your browser.