tags:

views:

764

answers:

3

I have a "proof of concept" piece of work that crosses over into some unfamiliar territory. I'm tasked with connecting an EFTPOS machine to an application running as an applet in a browser on our intranet.

I've ignored the EFTPOS dll for the moment and created a simple JNI decorated DLL in my language of choice (Delphi) that just logs a string to a text file in c:\ and I can call it successfully from a local Java application.

However, when I create an applet to do the same thing, compile it into a .JAR, sign the JAR & try to call the method in the applet via Javascript on a web page it fails.

A senior Java guy I'm working with doesn't think it will be possible to get this to work because it's inherently "evil" to allow an applet to do this.

There is an entry you can put in a java.policy file to allow loadLibrary. as well as allPermission & I've tried a whole host of variations along those lines all to no avail producing the following error trace in the Java Console:

java.lang.ExceptionInInitializerError
  at app.TestApplet.LogAString(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.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.JSClassLoader.invoke(Unknown Source)
  at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
  at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
  at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
  at java.security.AccessController.doPrivileged(Native Method)
  at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.DLoggerImpl)
  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.checkLink(Unknown Source)
  at java.lang.Runtime.loadLibrary0(Unknown Source)
  at java.lang.System.loadLibrary(Unknown Source)
  at app.DLogger.<clinit>(Unknown Source)
  ... 16 more
java.lang.Exception: java.lang.ExceptionInInitializerError
  at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
  at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
  at java.security.AccessController.doPrivileged(Native Method)
  at sun.plugin.com.DispatchImpl.invoke(Unknown Source)

The key line seems to be "Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.DLoggerImpl)" which implies a permissions problem. It could be that I'm getting the policy file wrong - or the signing wrong - or stuff like that or it could be that Java is hardwired to not allow those sort of permissions for an Applet because of the security risk.

My question is am I wasting my time? Can it be done & if so, how?

Thanks in anticipation

Mike

A: 

The only thing I can suggest is taking a look at the source code for that area and trying to decipher if it is not allowing because of lack of permission or because that is not allowed at all. You don't have line numbers unfortunately, so that makes it a little more tricky.

Michael Wiles
I'm going in - wish me luck
mcottle
A: 

I am pretty sure you cannot load a native library from an Applet unless it is "signed", and then the user will get an acceptance dialog to allow or disallow. That is, assuming you can do JNI at all in an applet... never tried that.

Good luck.

cjstehno
The applet's signed. The problem boils down to either 1) I haven't written the permissions correctly. 2) It's hardwired into Java somewhere that it can't be done.
mcottle
+3  A: 

You can definitely accomplish this. I have a working applet in production that does exactly this. Even if your applet is signed, you still need to use the Access Controller to access the dll, you cannot just call "loadlibrary". You can add this to the Java policy file however this is not recommended due to 1. You probably do not have access to the users java configuration. 2. Even if this is for your own company use, managing the policy file is a pain as users will download some JRE and your policy file is either overwritten or ignored.

You best bet is to sign your jar, making sure to wrap your load library code in a privileged block of code like this.

try{
    AccessController.doPrivileged(new PrivilegedAction()
    {
        public Object run()
    {
        try
        {
                    // privileged code goes here, for example:
         System.load("C:/Program Files/.../Mydll.dll");

         return null; // nothing to return
         } 
                 catch (Exception e)
         {
             System.out.println("Unable to load Mydll");
         return null;
         }
    }
     });
} 
    catch (Exception e)
{
        System.out.println("Unable to load Mydll");
}

You can Also use System.loadlibrary(mydll.dll) but you have to have the dll folder on the path in windows so the applet can find it.

If you need some source samples for calling the JNI functions let me know I can grab that as well.

Knife-Action-Jesus