1 Reply Latest reply on Aug 15, 2005 4:30 PM by Mike Boni

    Signed Applet gets AccessControlException calling EJB

    Mike Boni Newbie

      I'm trying to use a Signed Applet to invoke a EJB3.0 Stateless Session Bean under JBoss 4.0.3rc1.

      I have signed all the .jar files the Applet uses, including jbossall-client.jar, the applet jar, and the jar containing the ejb3 remote interface.

      I know my applet has been granted signed permissions, since I can invoke System.getSecurityManager.checkPermission(new RuntimePermission("accessDeclaredMembers")); within the applet without throwing an exception.

      I can use a JNDI lookup to find both the JBoss InitialContext and the remote proxy for the bean. (This failed when the applet was unsigned, since I get swapped between and 192.168.x.x as my server IP, but the problem went away after signing).

      However, when I actually invoke a remote method on the stub, I get an exception:

      java.security.AccessControlException: access denied
       (java.lang.RuntimePermission accessDeclaredMembers)
       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.checkMemberAccess(Unknown Source)
       at java.lang.Class.checkMemberAccess(Unknown Source)
       at java.lang.Class.getDeclaredMethods(Unknown Source)
       at org.jboss.aop.util.MethodHashing.getInterfaceHashes(MethodHashing.java:135)
       at org.jboss.aop.util.MethodHashing.calculateHash(MethodHashing.java:204)
       at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:61)
       at $Proxy0.getServerInfo(Unknown Source)
       at com.cpex.mpv.gui.MpvApplet.getServerInfo(MpvApplet.java:129)
       at com.cpex.mpv.gui.MpvApplet.init(MpvApplet.java:50)
       at sun.applet.AppletPanel.run(Unknown Source)
       at java.lang.Thread.run(Unknown Source)

      So where did my permissions go?

      Anyone have an idea? Is this just a bug?

      My best guess is that the Applet has been given permissions by the AppletClassLoader, which knows that the code came from a signed .jar file. However, the remote proxy class ($Proxy0) may have been created with a different ClassLoader, one that is not paying attention to the signed nature of the jar. Can anyone confirm or deny this guess?