Skip to end of metadata
Go to start of metadata

Could someone please fill this in? The mailing list archives have this issue a number of times.

Applet security problems

Introduction

There are a series of problems related to Applet security, not directly related to GeoTools, but that are interesting to consider.

Interacting with multiple servers

Java imposes a lot of security restrictions on Applet, in particular with three potential dangerous actions:

  • an Applet cannot open a file on the client file system;
  • an Applet cannot open a connection with a server different from the server from which the Applet is downloaded;
  • an Applet cannot use JNI native library.

These three restrictions are very limiting when we make GIS systems, because we often read maps from different servers and in some circustances we use the ECW protocol and his JNI native libraries.

If we make one of these three actions in a normal Applet (an untrusted Applet) we have a java.security.AccessControlException. The solution is to sign our Applet so it can be considered a trusted Applet from the JVM. The procedure to sign an Applet is very standard and can be found in the Java Tutorial. There is no need to sign the GeoTools packages. Only our Applet must be signed.

HTML scripts - Applet interaction

GeoTools is very usefull when we develop WebGIS systems, for example dynamic pages with a lot of DHTML and an Applet that serves only the scope to view maps, so an Applet with only a MapPane and a lot of interaction between DHTML scripting code and Java code. In this situation we have a big problem: also if we sign our Applet we can have security exception when we call Applet public methods from scripting code (i.e. JavaScript or VBScript functions) in a precise situation: if the script code calls an Applet method that result in the executution one of the three potential dangerous actions, we always have a security exeption. This is a Java design decision, so there is no way to resolve the problem by signing the Applet. This situation can occur for example when we have a DHTML toolbar with the common GIS tools (zoom, pan, full extent, ecc...) and we want to execute actions on the Applet from this toolbar.

There is however a trick. The Java Virtual Machine knows that how causes the execution of the dangerous action is the scripting code, by looking to the stack trace. So if we separate the stack trace of the scripting interation with the Applet, from the dangerous action execution, we have resolved the problem.

The solution is shown in this code:

try {
    AccessController.doPrivileged(
        new PrivilegedExceptionAction() {
        public Object run() {
               veryDangerousAction(); return null; }});
} catch( PrivilegedActionException e1 ) {
    e1.printStackTrace();
}

As you can see, the call of the veryDangerousAction() method is launched by a thread, so in a different the stacktrace. Put this code in the methods called from scripting code and the problem is solved.

  • No labels