1

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.

Ned Batchelder
  • 364,293
  • 75
  • 561
  • 662
Red33mer
  • 810
  • 3
  • 15
  • 22

4 Answers4

8

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
  • 3,503
  • 3
  • 30
  • 36
  • 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 Nov 22 '09 at 16:51
  • 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 Paljak Jul 14 '10 at 07:12
  • Thanks, this was my problem, things weren't working when called from javascript. – Andrew Niefer Nov 11 '10 at 19:37
0

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
  • 588,226
  • 146
  • 1,060
  • 1,140
  • 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 Nov 27 '09 at 09:42
  • If your supplementary jars are not signed, the applet WILL start, but will fail when any permission-requiring actions are attempted. – Bozho Nov 27 '09 at 10:02
0

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
  • 18,082
  • 23
  • 88
  • 136
  • You can not change a security manager when there is one active. – David Nouls Nov 27 '09 at 19:20
  • 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 Nov 28 '09 at 09:34
  • 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 Nov 28 '09 at 09:51
  • Besides, if you pay attention the poster is doing similar technique within the policy file: *permission java.security.AllPermission*; – Miguel Ping Nov 28 '09 at 09:53
0

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
  • 1,895
  • 12
  • 21