Problem 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 to read files. 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:
java.security.AccessControlException: access denied (java.io.FilePermission E:\Miscellaneous\SailJazz read)
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.checkRead(Unknown Source)
at java.io.File.exists(Unknown Source)
at java.lang.Thread.run(Unknown Source)
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 or usage 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?
Applets are not allowed to read client files (and that is good). You must store the
files on the same server as the applet and upload them using a http connection.
Please read the question!
thanks for the response.
My applet works fine using the jre version 1.3.1. It is a local application that does NOT involve a host. The applet read files from my harddrive.
When I installed jre version 1.4.2 I get the FilePermission read error.
My question(again) is: What's changed with jre version 1.4.2 that an applet that works with 1.3.1 does NOT work with 1.4.2??? How do I get my applet to work with 1.4.2???
If you have not changed the "sandbox" your policy should work.
Did your set-up work with any of the 1.4 versions?
Have you tried any other release build of 1.4.2?
Is there a reason you have not yet installed 1.5.0_x?
There have been some problems in some areas with different releases of the JDK which were corrected in later releases. I don't know if policies were affected by any of these problems.
I dont know all the details but the security management has changed since then.
If you use it as a local application you are just using the Panel/JPanel capabilities of the applet.
Why don't you use a Panel/JPanel extension
instead, just change the "extends JApplet" to "extends JPanel".
I have tried other versions of 1.4 but had problems with them (they'd hang my system) so I uninstalled them. I'm on Windows 98. Version 1.3 has all the features I need.
My applet does NOT use any Jxxx classes. It was written long ago with Applet and Frame. The GUI is not the important part of the applet. Its purpose is to search thru files (can be thousands) for requested matches and to display the results in the browser.
I suppose that version 1.3 was too loose and that the security has been tightened in later versions.
Any ideas on what I need to change to get my applet to work in version 1.4 as well as in 1.3???
An Applet that uses no applet features can be replaced by a Panel extension stuffed
into a Frame (still: just change the "extends Applet" to "extends Panel").
You could then save the search results in a formattet html file and start
up the browser (using a Runtime object in a thread) and supply the output file path as
For your application I cannot see any need for using applet (or browser for that matter).
Description of application
I didn't explain the application as I don't think its relevant to the problem.
I don't see how using a Panel or any other GUI can affect Security. Could you please explain the relationship?
Remember the Applet works with 1.3. What has changed and what do I need to change to get it work with 1.4?
But since you want to change my design, I'll explain it a bit.
An example might be the Java Tutorial which can be downloaded in a zip file and unzipped to files on your harddrive. I rewrite the search page to use my applet and am able to search all the pages of the tutorial for ...
Keep the logics, change GUI strategy
I have no intent on changing your logical design, what I suggested was that you
could change it into an application, that is, make it a Panel extension instead
of an Applet extension, Applet is a Panel descendant with web capabilities,
if you dont utilize any of those, and you just want to download pages from
web, you could just as well make it into a Panel and supply it with a main
method where you wrap the Panel (previously known as Applet) in a Frame.
I don't know the specifics of the security upgrades that has been done
after the java version you use became an oldie....
But, since you have explained your task now, I think maybe the little
application I have attatched here can be useful. You should at least check it
out. It is an app that performs multiple simultaneous downloads of web site content.
The SiteConn class contained here can easily be modified to perform
bytestream download for zip file retrieval.
Last edited by sjalle; 08-02-2005 at 03:33 AM.
thanks again for the response.
Let me explain a little more. I have a large number of html pages on my harddrive that I use the browser to read. For example the Java Tutorial download from sun. There is a search page somewhere within those pages that I have tailored to do a local search on the pages on harddrive vs on the web.
I want to be able to do searches while in the browser looking at the files for a particular topic. I didn't want to have to start a new, separate application to do a search, search for the folders to be searched and start a new browser invocation with the results of the search.
Well, then I see no other possible solution than:
1: resinstall the 1.3 java
2: try to hack the security management on 1.4 java if you can locate the source
the applet (far out solution).
Others may have better solutions, but for the time being I must say that
I doubt it; The strategy you have chosen is not exactly the right way to go
Last edited by sjalle; 08-02-2005 at 01:25 PM.
Change design? Or correct the policy?
Thanks again for the response.
I'm not sure why I should reinstall Java 1.3. I have jre 1.3 installed and am able to use it with both the NS and with IE browsers. I would like to move on to jre 1.4 but am unable to give FilePermission.
The documentation leads me to believe that it is possible to give an applet permission to read all the files in a directory (and in subdirectories???) So I have designed an application that requires that capability. And it works with jre 1.3.
The Tutorial gives an example:
Type the following in the text box to the right of the list labeled Target Name to specify all files in the C:\TestData\ directory:
However, I am not able to get that to work with either 1.3 or 1.4?
The general question is: How do you debug incorrect policy statements?
It's a problem similiar to the problem with incorrect classpath. Nothing works until you get it correct. Beginers often have to change and change and change it until they understand how it works and can corretly code it. I still have had problems and have written some tools to help me diagnose the problem.
Has anyone found such a technique with the policy files?
I meant reinstall 1.3.1 of course.
In my opinion you are "barking up the wrong tree". You spend day after day trying
to make something work, and that something is in conflict with the fundamentals
of the programming language you use.
Have you considered installing tomcat and set your localholst up with a servlet for
doing the file retrieval ? I think that would be much cleaner and faster to implement
than the things you are struggling with.
Back to basics
Actually I have my search program working in 4 different configurations:
1) Standalone appllication
2) In an applet (this one has the problem with jre 1.4.2
3) As a servlet
4) As a part of a special server that lives in a jar file with the files to be executed.
These are all working except for the problem with 1.4.2
Now the basics:
You can restrict/give permission to Java programs many ways. One of them is FilePermissions. It is possible to give permission to an applet to read from a harddrive by giving it permission. That permission is given by using the policytool to create an entry in the .java.policy file. I have done all that for jre version 1.3.1. Unless Sun has drastically redesigned Java to no longer use the policy file for applets, its a question of the correct syntax.
Is your position that it is NOT possible to give an applet FilePermission?
It is NOT my position that it is impossible to give an applet FilePermissions. My
position is that the applet is intended for the web and whatever permissions you grant
it by whatever means is something that the client machines out there completely ignores.
It might be useful on an intranet, but then again, I would have set it up as
As you may have noticed I have never written any code for tweaking the
security management for applets. I would never dear to spend days on such a
problem if I was doing professional project work, I would have changed my strategy.
But you are doing this as a private investigation, and no matter if you succeed or
not, such probings can be very educational.
My only point was that (according to your description of your stategy) it looked to me
like you were "crossing the river to get some water". Judging by the problems you are
having it is obvious that Sun has "drastically redesigned Java to no longer use the policy file
for applets", and that these changes are not only syntactical.
Please come back and tell us how you did it if you fix it.
So, in short, all I can say is good luck !
Last Post: 05-27-2008, 11:17 AM
Last Post: 03-21-2007, 03:28 PM
Last Post: 12-13-2001, 12:06 PM
Last Post: 11-14-2001, 07:02 AM
By Alan Amos in forum Architecture and Design
Last Post: 02-21-2001, 10:46 AM
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center