Why does my applet get a java.security.AccessControlException: access denied (java.net.SocketPermission ...), and how can I avoid it?

Question

We are clueless about why my client is encountering a Java Security exception in Safari. Could anyone help?

The exception occurs reliably in Safari on Windows. This involves a Java applet. The exception also occurs with Firefox and IE8 on Windows Vista.

Here are the steps to reproduce:

1. Open Safari on Windows

2. Click here: http://www.cengraving.com/s/item?itemId=CH003

3. Click "Customize" (at bottom of screen)

4. After the "Instant Proof" page loads, click "Add to cart."

Full stack trace:

java.security.AccessControlException: access denied (java.net.SocketPermission www.cengraving.com resolve)
    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.checkConnect(Unknown Source)
    at sun.plugin.security.ActivatorSecurityManager.checkConnect(Unknown Source)
    at java.net.InetAddress.getAllByName0(Unknown Source)
    at java.net.InetAddress.getAllByName(Unknown Source)
    at java.net.InetAddress.getAllByName(Unknown Source)
    at java.net.InetAddress.getByName(Unknown Source)
    at sun.net.www.http.HttpClient.New(Unknown Source)
    at sun.net.www.http.HttpClient.New(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source)
    at com.designapplet.a.f.a(Unknown Source)
    at com.designapplet.ui.c.a(Unknown Source)
    at com.designapplet.ui.c.for(Unknown Source)
    at com.designapplet.ui.DesignApplet.buy(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.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.GeneratedMethodAccessor2.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.plugin.liveconnect.PrivilegedCallMethodAction.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)
java.net.MalformedURLException: no protocol: 
    at java.net.URL.<init>(Unknown Source)
    at java.net.URL.<init>(Unknown Source)
    at java.net.URL.<init>(Unknown Source)
    at sun.plugin.liveconnect.SecureInvocation.checkLiveConnectCaller(Unknown Source)
    at sun.plugin.liveconnect.SecureInvocation.access$000(Unknown Source)
    at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)
java.net.MalformedURLException: no protocol: 
    at java.net.URL.<init>(Unknown Source)
    at java.net.URL.<init>(Unknown Source)
    at java.net.URL.<init>(Unknown Source)
    at sun.plugin.liveconnect.SecureInvocation.checkLiveConnectCaller(Unknown Source)
    at sun.plugin.liveconnect.SecureInvocation.access$000(Unknown Source)
    at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)

Answer 1

You can override the default security policy file used by the SecurityManager.

1) Create a text file (eg. applet.policy)

2) Grant all permissions to the applet

  grant {
   permission java.security.AllPermission;
  };

3) Run the applet with

-J-Djava.security.policy=applet.policy

Answer 2

i had the same problem. And solved this by self signing the applet...

used the following steps and it worked

javac AppletClass.java
jar cvf AppletClass.jar AppletClass.class
keytool -genkey -validity 3650 -keystore pKeyStore -alias keyName
keytool -selfcert -keystore pKeyStore -alias keyName-validity 3650
jarsigner -keystore pKeyStore AppletClass.jar keyName

just answer the questions it will ask and it will do the work

NOTE : i was getting the error for local read/write file

Answer 3

I have the same problem! JavaScript calls a public method of an applet that is embedded in the same document. This should trigger that the applet loads some data from "home", so the connection should be opened to the same domain from where the applet was loaded - which should be allowed also for unsigned applets without further privileges.

I also recognized this security exception only with Safari (5.0.2 for Windows, JRE 1.6.0_22). The same applet in IE and FireFox is doing well.

I also believe that this is a bug in the Java Sandbox of Safari.

---

EDIT: Using doPrivileged did not help but I found this workaround: If you "decouple" the JavaScript call from the requested execution through a timer event, the execution will no longer be prohibited by the security restriction that Safari puts into the game here. In detail:

• the method that is called from JavaScript only creates a javax.swing.Timer (to schedule one event so the repeat-property must be set false). You can set the delay quite short (e.g. 50 ms).
• The method call that is intended to be called has to be put into the ActionEvent listener (actionPerformed) which is called by the timer.

One problem that might make things a bit more complicated is that in the actionPerformed context only static variables are accessible. If the JavaScript call contains variables, these must be put by the initially called method into a staic "buffer" variable from which the scheduled event can read the value afterwards.

In my tests only the javax.swing.Timer provided the required decoupling whereas java.util.Timer could not be used for that purpose.