I have read everywhere that unsigned Java applets are not allowed to make network connections to any server but the one which originated the applet. This is OK for my application since my applet only needs to talk to the server. However, when I wrote a test applet to try opening a socket to communicate with a process on my development machine, it throws the following exception:
Error establishing socket connection: java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:11000 connect,resolve)
The code which caused the exception:
private void sendMsg(String msg) {
Socket s = null;
try {
s = new Socket("localhost", 11000);
}
catch (Exception e) {
System.err.println("Error establishing socket connection:");
e.printStackTrace();
return;
}
try {
OutputStream out = s.getOutputStream();
out.write(msg.getBytes());
out.flush();
s.shutdownOutput();
s.close();
}
catch (Exception e) {
System.err.println("Error in writing to the socket:");
e.printStackTrace();
}
At first I thought it was a problem in my code that my inexperience had caused me to miss. However, I get the same exception when trying to run the Talk Server example from the official Java Tutorials. This leads me to believe that I actually have a setup problem, or a misunderstanding of the default security restrictions. Does the default security manager prevent you from opening sockets to the machine running the applet even if it is also the machine serving the applet? If so, that is a problem for me because the deployed system will need to allow a user logged in on the actual server to use the same applet that a remote user would use. Is there a way around the exception I'm getting that doesn't involve signing the applet? I don't want to go to the trouble if not necessary.
NOTE: I know it would be better not to have users access the applet from the server. That wasn't the original design, but practical considerations unfortunately forced this implementation compromise on me.
UPDATE: Viewing the applet's page from a webserver solves the problem. Even if the server is localhost. The security update in Java 1.6.0_11 only applies to applets loaded directly from the local file system.