applet can't read files in document base with IE & Sun Java 1.4.2

[RowdyRednose]

My applet reads the contents of a document relative to the document
base. This does not work in IE using Sun Java 1.4.2 when loading the
applet from the file system (url=file:/...). I get an exception (see
below).

However, doing one of the following changes - but not changing one bit
of the java code - makes it work:
1) using MyApplet.class directly instead of packaging it in a jar
2) loading the applet from an http server
3) using the MS VM or an SunVM < 1.4.2
4) using Mozilla (and Sun 1.4.2)

Only option 1) would allow any user - regardless of his/her
configuration - to use the applet.
As users must be able to start it from disc oder harddrive, 2) is no
option for me.

Has anyone another solution to this problem? I WANT to use Jars
because I have many classes...

--
java.security.AccessControlException: access denied
(java.io.FilePermission C:\...\file.txt 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.isDirectory(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.connect(Unknown
Source)
at sun.net.www.protocol.file.FileURLConnection.getInputStream(Unknown
Source)
at MyApplet.start(Unknown Source)

 

[ak]

My applet reads the contents of a document relative to the document

base. This does not work in IE using Sun Java 1.4.2 when loading the
applet from the file system (url=file:/...). I get an exception (see
below).

is your jar signed?

 

[RowdyRednose]

My applet reads the contents of a document relative to the document

is your jar signed?

No. Why should it be? I'm just reading a document from the document base.

 

[Andrew Thompson]

3) using the MS VM or an SunVM < 1.4.2
4) using Mozilla (and Sun 1.4.2)

I am not convinced that the 1.4.2 JVM
acted differently in two different browsers,
*unless* the HTML is invalid and one browser
was more forgiving of an error and included
an archive/codebase the other did not.

What is an example URL?

The only other possibility I can think is
that you were perhaps misled by applet
and/or resource caching.

Ultimately though, as ak suggested, I
suspect the code needs to be signed to
avoid a SecurityAccessException..

 

[Andrew Thompson]

No. Why should it be? I'm just reading a document from the document base.

It is not that simple, if you attempt to instantiate
a File object at *any* point (even in the course of
finding your URL) you will hit the SecurityManager..

Your results were confusing and not *entirely*
consistent with the answer 'sign code', but that
'AccessControlException' is particularly telling..

What's your URL, code?

[ I can do more tests in three minutes with an
URL and code than we can achieve in a week of
'is it..?', 'have you checked..?' ]

 

[Roedy Green]

No. Why should it be? I'm just reading a document from the document base.

It had better be on the same server as the jar then.

 

[Andrew Thompson]

On Tue, 27 Jul 2004 15:10:53 +0200, RowdyRednose


It had better be on the same server as the jar then.

It seems to be on the same server (from comments
earlier trimmed), but the results are not entirely
consistent or logical..

 

[RowdyRednose]

It is not that simple, if you attempt to instantiate

a File object at *any* point (even in the course of
finding your URL) you will hit the SecurityManager..

No - the applet works fine when using it via http:// as I wrote.
I do not use "File" etc. I also don't distinguish between "file:/" and
"http:/" URLs, which is - if it works - a really nice thing...

What's your URL, code?

I somehow "lost" my stripped down version of that applet which shows that I
really only open an URL. But I'll make a new one tomorrow and will post it
here.

 

[RowdyRednose]

Here are the file contents of a stripped-down example so anyone can
reproduce the problem.

Instructions:
- Put the 2 files shown below into a directory
- Put any file named "demo.txt" into that directory (e.g. copy index.html
demo.txt)
- Compile MyApplet.java (javac -target 1.1 MyApplet.java)
- Create a jar file "ma.jar" that contains only "MyApplet.class" (jar cf
ma.jar MyApplet.class)
- Open "index.html" in IE using the newest Sun Java 1.4.2
- Open Sun Java Console
- Press Button on HTML page => see Exception

Remarks:
- Opening the file works when started from method "start()", but does not
work when started via the Button on the HTML page (JS->Java).
- removing the "archive" attribute solves the problem in IE
- Mozilla has no problems with it
- IE using MS own VM or an older Sun VM has no problems with this, too

-- <MyApplet.java> --
public class MyApplet extends java.applet.Applet {
public void start() { open(); }
public void open() {
try {
System.out.println((new java.net.URL(getDocumentBase(),
"demo.txt")).getContent());
} catch (Throwable t) {
t.printStackTrace();
}
}
}
-- </MyApplet.java> --

-- <index.html> --
<HTML>
<BODY>
<applet id="myapplet" archive="ma.jar" code="MyApplet" width="10"
height="10"></applet>
<input type="button" value="open" onclick="myapplet.open()"/>
</BODY>
</HTML>
-- </index.html> --

 

[Andrew Thompson]

Here are the file contents of a stripped-down example so anyone can
reproduce the problem.

I did yes, and I think I have found the problem..

<applet id="myapplet" archive="ma.jar" code="MyApplet" width="10"
height="10"></applet>
<input type="button" value="open" onclick="myapplet.open()"/>

I did not look closely at your HTML, just
copy/pasted and saved. When I loaded it I
was surprised to see the button which was
not mentioned in the applet code..

To be honest I did not realize you could call
an applet like that (though I am familiar with
the existence of direct applet/JS interaction)..

In any case, that seems to produce a more
constricted Security manger. I clicked your
button and saw the errors you mentioned, then
I moved the call to 'open()' into an 'init()'
and everything seems to work as intended,
you get an URL back and the file contents..

HTH

 

[RowdyRednose]

In any case, that seems to produce a more

constricted Security manger. I clicked your
button and saw the errors you mentioned, then
I moved the call to 'open()' into an 'init()'
and everything seems to work as intended,
you get an URL back and the file contents..

Do you mean you just changed the method name from "open()" to "init()" in
the applet and called "myapplet.init()" when clicking the button?

That would mean the java.applet.Applet methods have more rights...

Have you an explanation for that? It's a bug, isn't it?
I need the combination of the following to get the Exception
- deploy applet in jar
- call method from JS
- use IE
- use Sun Java 1.4.2
- open applet from "file:/", not "http:/"

Just changing one of these points makes the bug disappear. I don't see why
the applet should be protected more when started from "file:/" instead of
"http:/".

 

[RowdyRednose]

In any case, that seems to produce a more

constricted Security manger. I clicked your
button and saw the errors you mentioned, then
I moved the call to 'open()' into an 'init()'
and everything seems to work as intended,
you get an URL back and the file contents..

As I mentioned in the first reply to your post, I'm not sure if I understood
what you meant. So I added 2 buttons to the html:

<input type="button" value="init" onclick="myapplet.init()"/>
<input type="button" value="start" onclick="myapplet.start()"/>

The body of the applet looks like this now (open() and init() are
identical):

public void start() { open(); }
public void open() {
try {
System.out.println((new java.net.URL(getDocumentBase(),
"demo.txt")).getContent());
} catch (Throwable t) {
t.printStackTrace();
}
}
public void init() {
try {
System.out.println((new java.net.URL(getDocumentBase(),
"demo.txt")).getContent());
} catch (Throwable t) {
t.printStackTrace();
}
}

But any click on any button still results in an exception. Only when started
programmaticaly, i.e. when "appletviewer" calls init() and start() by
itself, it works without exception.

 

[Andrew Thompson]

Do you mean you just changed the method name from "open()" to "init()" in
the applet and called "myapplet.init()" when clicking the button?

Nuh.. *added* init..
<code>
public void init() {
open();
}
</code>

Thereafter left the button well alone..

That would mean the java.applet.Applet methods have more rights...

Have you an explanation for that?

No. I suspect the details are buried deep in the
literature somewhere, but perhaps..

It's a bug, isn't it?

(shrugs) Maybe.. I do not have the time
(nor inclination) to pursue it further,
though it may be worth your while.

BUT, perhaps this can be solved by signing
the applet to make the Sun VM happy, it may
be quicker and more effective than any other
course of action..

HTH

 

[RowdyRednose]

Nuh.. *added* init..

<code>
public void init() {
open();
}
</code>

Thereafter left the button well alone..

That's what I already showed in my "start()" method...

 

[zoopy]

Here are the file contents of a stripped-down example so anyone can
reproduce the problem.

Instructions:
- Put the 2 files shown below into a directory
- Put any file named "demo.txt" into that directory (e.g. copy index.html
demo.txt)
- Compile MyApplet.java (javac -target 1.1 MyApplet.java)
- Create a jar file "ma.jar" that contains only "MyApplet.class" (jar cf
ma.jar MyApplet.class)
- Open "index.html" in IE using the newest Sun Java 1.4.2
- Open Sun Java Console
- Press Button on HTML page => see Exception

Remarks:
- Opening the file works when started from method "start()", but does not
work when started via the Button on the HTML page (JS->Java).
- removing the "archive" attribute solves the problem in IE
- Mozilla has no problems with it
- IE using MS own VM or an older Sun VM has no problems with this, too

-- <MyApplet.java> --
public class MyApplet extends java.applet.Applet {
public void start() { open(); }
public void open() {
try {
System.out.println((new java.net.URL(getDocumentBase(),
"demo.txt")).getContent());
} catch (Throwable t) {
t.printStackTrace();
}
}
}
-- </MyApplet.java> --

-- <index.html> --
<HTML>
<BODY>
<applet id="myapplet" archive="ma.jar" code="MyApplet" width="10"
height="10"></applet>
<input type="button" value="open" onclick="myapplet.open()"/>
</BODY>
</HTML>
-- </index.html> --

I've tried your applet with JRE 1.5.0b2 in both Mozilla 1.7 and IE6. I didn't encounter any
problems, neither when executing it from file system (file://) nor from webserver (http://).

Sun's bug database shows a couple of bugs which seem to be related (4816480, 4982417, 4697178 [space
character in path?]), but they are closed or have been reported against earlier version than 1.4.2.

May be you could enable tracing (press 5 in Java console, 0 to switch off) and see if that might
give you a clue. [warning: first time you press the button, you might see many lines scrolling by on
the console]

Regards,
Z.

 

[RowdyRednose]

I've tried your applet with JRE 1.5.0b2 in both Mozilla 1.7 and IE6. I didn't encounter any

problems, neither when executing it from file system (file://) nor from webserver (http://).

Hm. Maybe it's fixed with 1.5. I'll check that. Did you follow all my
steps to reproduce the problem (especially putting the class into a
jar)?

Sun's bug database shows a couple of bugs which seem to be related (4816480, 4982417, 4697178 [space
character in path?]), but they are closed or have been reported against earlier version than 1.4.2.

I checked these bugs. No one matches my problem

But I found one which does: 5011139.

Since the bug won't be fixed I'll have to implement the workaround
(see comments in bug 5011139) using a Thread (Runnable)...

 

[John C. Bollinger]

Do you mean you just changed the method name from "open()" to "init()" in
the applet and called "myapplet.init()" when clicking the button?

That would mean the java.applet.Applet methods have more rights...

Have you an explanation for that? It's a bug, isn't it?

It would seem to be an IE problem, since you report that it does not
occur in Mozilla with the same JRE. I speculate IE causes scripts to
run in a more restricted security context than it applies to applets, or
perhaps that it just mucks up the works. I observe that some URIs used
for referencing Jar members would camouflage the fact that the requested
file is in the applet's document base, and I can imagine (vaguely) ways
in which IE might supply information to the JRE that causes your applet
to exhibit the buggy behavior.

I need the combination of the following to get the Exception
- deploy applet in jar
- call method from JS
- use IE
- use Sun Java 1.4.2
- open applet from "file:/", not "http:/"

Good luck.

Just changing one of these points makes the bug disappear. I don't see why
the applet should be protected more when started from "file:/" instead of
"http:/".

The issue surely revolves around accessing the local filesystem, which
is why the suggestion to sign the jar makes good sense. I agree that
what you're trying to do _should_ work without signing the Jar, but
given that it doesn't, you're better off to look for a workaround than
to hope for a quick vendor fix.


John Bollinger
(e-mail address removed)

 

[Daniel Hagen]

Though youe are using an unsigned applet I think you might be
encountering a problem I had some time ago using a signed applet.

The short version is that in Sun Plugin 1.4, even for signed applets, no
permissions are given when called from javascript.
You explicitely have to call AccessController.doPrivileged([...])

See http://forum.java.sun.com/thread.jsp?forum=63&thread=442390

Regards

Daniel