My setup
Server is running on a machine on the network. It is going to run from an applet but for now it is standalone app.
Client is running from an applet but for testing purposes can run standalone.
Standalone client connecting to standalone server works perfect.
The problem
When the client is an applet I am getting security exceptions. I have looked all over the web and tried just about everything. I have tried playing with the crossdomain.xml giving all permissions with no luck. My jar is signed using the technique found here http://ezzatron.com/2009/09/29/automatically-signing-jar-files-in-netbeans/
I need to know what I could possibly doing wrong and if it is even possible to load the client on an applet, Make a TCP connection to a server (which is ran on applet or standalone). If none of this is possible, is JNLP an alternative?
try the following
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
// put the line of code here that is causing the security exception
}});
Where am I putting this snippet of code? Inside of the applet?
yes in your code, find the line in your code that is causing the exception to be throw (you can narrow it down with a bunch of System.out.println()'s, if not then from the java console). Then wrap the line in the above code.
I tried that but I am still getting the same error. It is looking for the crossdomain.xml on the server I am connecting to, however the sever is not running HTTP. It is only a server in the sense of TCP connection. I am not sure how to handle this. I have read conflicting articles about network connections working perfectly fine between applets and others that say it is not possible.
[java]
java.security.PrivilegedActionException: java.io.IOException: Server returned HTTP response code: 500 for URL: http://SERVERIP/crossdomain.xml
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source)
at sun.plugin2.applet.Applet2SecurityManager.checkConnect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at Network.Client.Client.connect(Client.java:76)
at code.ISThread$1.run(ISThread.java:70)
at java.security.AccessController.doPrivileged(Native Method)
at code.ISThread.<init>(ISThread.java:64)
at code.SimController.Initialize(SimController.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSInvoke.invoke(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin2.liveconnect.JavaClass$MethodInfo.invoke(Unknown Source)
at sun.plugin2.liveconnect.JavaClass$MemberBundle.invoke(Unknown Source)
at sun.plugin2.liveconnect.JavaClass.invoke0(Unknown Source)
at sun.plugin2.liveconnect.JavaClass.invoke(Unknown Source)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo$DefaultInvocationDelegate.invoke(Unknown Source)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo.doObjectOp(Unknown Source)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo$LiveConnectWorker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Server returned HTTP response code: 500 for URL: http://SERVERIP/crossdomain.xml
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at com.sun.deploy.net.CrossDomainXML$2.run(Unknown Source)
… 33 more
[/java]
In applets you are only allowed to connect to the server the applet was loaded from, dunno if the snippet by faust should change that, but by default it is so.
That restriction should only apply to non signed applets, signed applets should be able to do anything a normal application can.
If all fails as a last resort you could turn off the security manager by doing a System.setSecurityManager(null);
But I would not recommend this as a long term solution and you should continue looking for a proper fix.
I guess the only option is to setup a lightweight HTTP server on port 80 to serve that file? That is, assuming your ISP doesn’t block port 80 …
Other than that, your applet can only connect to the server on which its hosted, unless the applet is signed and the user gave it full permissions.
I have tried all the combinations of the following
-Signing the jars of both applets
-Hosting both applets on a web server.
-Using the security code posted above
-Using the crossdomain.xml
-In the VM runtime of the applet java -Djava.security.manager applet.policy
With applet.policy being
[java]
grant {
permission java.security.AllPermission;
}
[/java]
All of the methods above result in 1 of 2 errors
Error 1. Permission denied when opening the socket
Error 2. It looks to the IP of the socket you are trying to connect to as if it was a webserver hosting a crossdomain.xml.
Maybe I am doing something wrong, but the other developer and I have spent 3 days testing every possible combination. Like I said above we have seen reports that it is possible and that it isn’t. Right now we are leaning towards it is NOT doable. However it could be one stupid little setting we are missing
Thanks for the input guys!
You might want to try some of the suggestions here:
We finally figured out what the problem is. I mentioned the policy file which gets created and the VM options are listed as -Djava.security.manager applet.policy, well this doesn’t seem to work. After basically reading the book on how java security works (located here What's the Main Goal? (Ch. 3, Sec. 1) [Securing Java]), it turns out there are 2 directories it always looks for policy files at. One being the install directory/lib/security of java and the other {Your OS HOME}/.java.policy file. We didnt have this HOME/.java.policy file. After putting it in place granting all permissions it worked.
However this brings me to the next question. Why didnt -Djava.security.manager applet.policy work? We tried giving it an absolute path to the applet.policy file and it still didn’t grant all permissions. Is there another setting we can use that points to a URL on the server or something