NeXtMidas, being written in Java, can be deployed in an applet context. At this time applets have been tested in both Netscape Navigator 4.x, Navigator 6.x and higher, and Mozilla. There a multitude of ways that applets can be executed depending on the quality of the network connection between the clients and the server and the JVM version on the client machines.
Applet deployments can be done in three ways. One way is to have the nextmidas directory structure available from the web (directory deployment) and one where the nextmidas directory structure is contained within Jar files (jar deployment). Both have advantages and disadvantages and have currently have varying levels of support based on the browser version being used. The third mechanism (mixed deployment) uses facets of both strategies.
Directory deployments are identified by the fact that the entire Nextmidas directory structure is available from the same codebase as the HTML file containing the applet. The browser will fetch each required class file and resource using a seperate request to the web server. This will cause a significant use of network bandwidth but requires less configuration than the jar deployment mechanism.
Jar deployments are identified by bundling the entire nextmidas directory structure into one or more jar files which are accessible through the web. The names of these jar files are identified in the HTML containing the applet. The browser fetches the jar files once and stores them in a local cache on the client machine. All class files and resources are then accessed from this cache. This method requires one large bandwidth hit when the applet is first loaded but then no bandwidth usage after that.
A mixed deployment uses a combination of the jar and directory deployment strategies. This has been identified as a deployment mechanism primarily due to functional restrictions on the part of Netscape 4.x until work arounds can be found.
Applet security considerations play a significant role in the
deployment of applets. Most useful Nextmidas applications require
unrestricted access to the client machine's resources. The rest of the
discussion in this section will center on how to grant this type
of access to NextMidas applets.
The security steps outlined here do not need to be performed for
applets deployed with jars.
Netscape 4.x
Netscape 4.x comes with its own implementation of a 1.1 compliant (more or less) JVM. Regardless of whether the client machine has an external JVM of a higher version this is the one that will be used when running applets within Netscape 4.x. Because of the old (circa 1998) JVM implementation the security model is quite different from newer browsers. The following steps must be followed for Netscape to recognize applets as having trusted permissions. These instructions assume the user is working on a Unix platform under csh.
- Start netscape. If this is the first time that netscape has been started on a particular client's machine, it will present some dialogs to the user. Accept these dialogs until all but the Navigator window is up.
- Exit netscape.
- From the command line execute '$NMROOT/os/unix/nmnav'. This will insert the appropriate configuration information into the netscape preferences to allow unrestricted execution. Nmnav is a C-Shell script that can be viewed with any text editor.
- Restart netscape.
Note that with Netscape 4.x you must use the Netscape signtool to sign the jar files. This tool can be retrieved at this link. http://developer.netscape.com/software/signedobj/jarpack.html
Netscape 6.x +
Starting with Netscape 6.x, Netscape no longer comes bundled with a JVM. At this point in the application history Netscape started to use the Java plugin architecture. This requires that a 1.2 or greater compliant JVM plugin be installed on the machine. This plugin is part of the standard Sun JDK distribution for JDK versions 1.3 and higher. When installing the JDK on a windows platform the configuring of the plugin will be done automatically. On Unix platforms a little more work might be required. The remainder of this section will assume that the plugin has been installed and works properly under Navigator.
Starting with JDK1.2 the security model changed significantly from the pre1.2 security model. To support these changes the following has to be done. The configuration of a security policy has been simplified down to the creation of a single policy file in the user's home directory.
Create a .java.policy file in your home area. ( The java.security file defaults to look here for a user .java.policy file ) which contains the following text:
// Standard extensions get all permissions by defaultgrant codeBase "file:${java.home}/lib/ext/*" {permission java.security.AllPermission;};
// default permissions granted to all domainsgrant {
// permissions needed to run the NeXtMidas Demospermission java.util.PropertyPermission "NMPID", "read";permission java.util.PropertyPermission "NMSF", "read";permission java.util.PropertyPermission "CWD", "read";permission java.util.PropertyPermission "user.dir", "read";permission java.util.PropertyPermission "HOME", "read";permission java.util.PropertyPermission "user.home", "read";permission java.util.PropertyPermission "USER", "read";permission java.util.PropertyPermission "user.name", "read";permission java.util.PropertyPermission "java.vm.info","read";permission java.io.file.FilePermission ".msf" "write";};Permissions can be added to this file as needed for new applets.