views:

558

answers:

4

I have an java applet running on tomcat 5.5. It is signed ( -selfcert). I still get an java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader) Exception, when my Applet tries to connect to a webservice (already in this line):

ws_locator = new My_WebserviceLocator(ws_adress + "?wsdl",
                new javax.xml.namespace.QName("http://impl.webservice", "My_Webservice"));

Since there are some similar questions here, an i read them:

  • Yes, the applet is signed. I checked it with -verify.

  • Tomcat security exception, may be, but i have added to catalina.policy:

    grant codeBase "file:/home/me/apache-tomcat-5.5.27/webapps/myapplet/-" {
        permission java.security.AllPermission;    };
    

    grant codeBase "file:/home/me/apache-tomcat-5.5.27/webapps/myapplet/applet.jar" { permission java.security.AllPermission; };

and the usual stuff like is also in there:

grant codeBase "file:${java.home}/jre/lib/ext/-" {
        permission java.security.AllPermission;
};

with no result.

Ok, quick update, adding:

grant{
        permission java.security.AllPermission;
};

to the local java.policy file fixes the problem. BUT thats not what i am looking for, the applet should run on an avarage machine, with dafault java.policy file. So it has to be fixed from within the code.

+3  A: 

Do you call your WS from the applet main thread or from a thread initiated by a call to the applet's method using javascript?

See example below.

Hope it helps.

public class MyApplet extends JApplet {

    @Override
    public void start() {
     // It will work if your applet is signed
     callWebService();
    }

    public void methodCalledFromJavascriptWrong() {
     // It will NOT work even if your applet is signed
     callWebService();

    }

    public void methodCalledFromJavascriptGood() {
     AccessController.doPrivileged(new PrivilegedAction() {

      public Object run() {
       // It will work if your applet is signed
       callWebService();
       return null;
      }

     });

    }

    private void callWebService() {
     //Here you call your web service
    }
}
Laurent K
no thats not it, the applet would't start otherwise, the applet does start and all the functionality works besides creating ws_locator and of coarse connecting to the webservice
Red33mer
Laurent K, can you explain why this is so? Are there any workarounds for this, so that I would not have to do the privileged action trick all the time? Where is it explained in detail?I have an applet that calls javax.smartcardio and most of the time is called through Javascript. I've seen tricks like creating a privileged thread for smartcard access but that would be over-engineering for me.
martin
A: 

If you are using other libraries (jars) from your applet, that interract with any restricted resource, they should also be signed. So give the whole stacktrace, and the My_WebserviceLocator. (And don't use underscores). For example try signing the axis.jar.

Bozho
as i wrote in a comment for, another answear, the applet does start, it does do everything that is supposed to do unless i write somewhere, anywhere the line of code u see in the question. The axis2 webservice stubs aber autogenerated by the wsdl2java script from the apache website
Red33mer
If your supplementary jars are not signed, the applet WILL start, but will fail when any permission-requiring actions are attempted.
Bozho
Try signing the axis.jar
Bozho
A: 

As a temporary workaround, you can disable the SecurityManager. Of course this have some security issues, but at least you will be able to track it down to the SecurityManager (ie, a permissions issue).

System.setSecurityManager(null);

If this indeed works, my guess is that you are configuring the wrong policy file. When running an applet from the browser, I'm almost sure that the applet launcher will be a regular consumer JRE, not the jre bundled with the JDK.

Miguel Ping
You can not change a security manager when there is one active.
David Nouls
IIRC, you couldn't back in 1.00, but you can (with sufficient privileges) now. I wish it didn't work. Some eejit decides that their applet wants to disable security, and it's disabled for every other applet out on the interwebs.
Tom Hawtin - tackline
Why the downvote? I am using this technique myself both with java web start and applets. @You cannot change a security manager when there is one active **and** you don't have permissions to change it.Besides this is not a solution, it's a quick hack to determine if the right policy file is being handled.
Miguel Ping
Besides, if you pay attention the poster is doing similar technique within the policy file:*permission java.security.AllPermission*;
Miguel Ping
A: 

Setting permissions on the server is not the solution. It is the security manager in the browser that complains.

The proposed use of AccessManager is indead mandatory or this will fail. But you also need to do the same when calling the webservice from start() or init().

Can I ask: is the WebService call the only reason why you have an applet ? It might be better to put a proxy servlet in place to avoid Same domain policy restrictions. Then you can use pure HTML + Javascript in the browser.

Calling into an applet from JS can fail if you do it before the applet is fully started, so you should wait for the applet to be ready.

David Nouls