Granting read FilePermission to an applet

I'm having problems trying to give read FilePermission to an applet under jre version 1.4.2_08 on a Win98 system. I had previously been using jre version 1.3.1 and had no problems using the applet. I had setup the .java.policy file using policytool. When I installed jre 1.4.2_08 the applet no longer works. It gets access denied FilePermission ... read errors.

For testing I have two browsers: NS 7.02 and IE 6.0. I have left NS using jre 1.3.1 plugin for its applets. It continues to work fine. When I configure IE to use jre 1.3.1 it works. When I change IE to use 1.4.2 it gets the access denied. FilePermission ... read error.

The CodeBase is set to a folder above where the jar file resides: file:/E:/Miscellaneous/-
I have several jar files within subfolders that use that same CodeBase hence the ending -
The target is set to the folder above the subfolders that the applet is to read: E:/Miscellaneous/SailJazz
I have other targets with an ending / that also don't work.

Have there been changes to the policy file contents between 1.3.1 and 1.4.2?

How does one find the problem? My prior experiences trouble shooting has been the shotgun approach: keep trying all possible combinations until it works. Surely there is a better way. Any ideas?

Thanks,

Hi,

Go to this link for a clear snapshot on permissions granted to an applet.
http://java.sun.com/docs/books/tutor...ur1/step1.html

Thanks for the response. I've read about using the policytool many times and have used it successfully in giving permissions to applets when they are running with the 1.3.1 plugin.
My question is: Is there something different with plugin version 1.4.2 that the old, working with 1.3.1, .java.policy file that needs to be changed for it to work with version 1.4.2???

Another question is: How to find and correct errors in giving permission. You don't get any messages if you've made a mistake, it just doesn't work. The only way I've found is to change it and change it and .... until it works. There must be a better way. Or is there?

I narrowed the problem to being when I called the Applet from Javascript within an HTML page in IE running jre 1.4.2
For example: document.myApplet.fromJS(str);

The applet in IE with 1.4.2 worked OK when called directly from the HTML.

I tried several codeBase= entries in the .java.policy file and could not find any that would work. So I gave up and added the FilePermissions to the global entry at the beginning of the file.

For example: The bottom 4 entries allowed IE to work.

grant {
...
permission java.io.FilePermission "E:/Testing/", "read";
permission java.io.FilePermission "E:\\Testing\\-", "read";
permission java.io.FilePermission "E:/Miscellaneous/SailJazz/", "read";
permission java.io.FilePermission "E:\\Miscellaneous\\SailJazz\\-", "read";
};

The following entries allowed NS with jre 1.3.1 to work:

grant codeBase "file:/E:/Java/Tutorial/-" {
permission java.io.FilePermission "E:/", "read";
permission java.io.FilePermission "E:/Java/Tutorial/", "read";
permission java.io.FilePermission "E:\\Java\\Tutorial\\-", "read";
};

grant codeBase "file:/D:/Testing/-" {
permission java.io.FilePermission "E:\\Testing\\-", "read";
permission java.io.FilePermission "E:/Testing/", "read";
};

Someday when I get inspired again, I'll try other codeBases to see if I can narrow it down.

Norm

I gave up on this for a while. It went away for a while when I updated the jre and then came back with the latest jre (6_U13). So I spent a day and found a workaround.
If I add permissions under the empty codeBase (<ALL>) it works, ie the program is able to read the files in the folders.
The codeBase <ALL> entry from my .java.policy file:

grant {
...
permission java.io.FilePermission "C:/Java/JDK1.6_doc/docs", "read";
permission java.io.FilePermission "C:/Java/tutorial", "read";
};

I tried many different combinations of codeBase, but only this one works.

Interesting stuff Norm - thanks for that, I'm going to save this thread as insurance :thumb:

The biggest difference between time and space is that you can't reuse time...
M. Furst