showdocument() problem (or bug?)

[maxmike]

I have a trusted applet that is supposed to generate a pdf file and
save it as a temporary file on the local machine, then display it.
Since display of such an animal can only happen with showDocument(URL,
type) I am trying to build the url using :
URL url = new URL("file:" + File.separator + File.separator +
"filename.pdf");

and this does indeed work IFF I run the applet locally. However, if the
bloody thing is running connected to the server, it does not. Then the
only command that works is
URL url = new URL(getCodeBase(), "filename.pdf");
so I had to bytestream the pdf down to server, have it install it in a
file and make the call. A real waste, considering I'm supposed to be
writing non-polluting software. Any ideas as to what's wrong with this?
Thanks.

 

[Roland]

I have a trusted applet that is supposed to generate a pdf file and
save it as a temporary file on the local machine, then display it.
Since display of such an animal can only happen with showDocument(URL,
type) I am trying to build the url using :
URL url = new URL("file:" + File.separator + File.separator +
"filename.pdf");

and this does indeed work IFF I run the applet locally. However, if the
bloody thing is running connected to the server, it does not. Then the
only command that works is
URL url = new URL(getCodeBase(), "filename.pdf");
so I had to bytestream the pdf down to server, have it install it in a
file and make the call. A real waste, considering I'm supposed to be
writing non-polluting software. Any ideas as to what's wrong with this?
Thanks.

I'd say your browser doesn't allow you to open a file from the local
file system.
When your applet is hosted on a remote server, the applet opening a
local filesystem file would be like a page from this remote server wants
to open a link like <a href="file:///C:/AUTOEXEC.BAT"> or <a
href="file:///etc/passwd">. Don't know for Internet Explorer, but
Mozilla does not allow this for security reasons.
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \

 

[maxmike]

I'd say your browser doesn't allow you to open a file from the local
file system.
When your applet is hosted on a remote server, the applet opening a
local filesystem file would be like a page from this remote server wants
to open a link like <a href="file:///C:/AUTOEXEC.BAT"> or <a
href="file:///etc/passwd">. Don't know for Internet Explorer, but
Mozilla does not allow this for security reasons.

Thanks, Roland - what you say makes sense; it happens to me in IE,
Netscape and Firefox. It's just that there are no complaints from
either Java or the browser.

Mike.

 

[Andrew Thompson]

...there are no complaints from either Java or the browser.

Really?! You're not swallowing exceptions* by any chance
are you? Your code should be throwing (big, fat, juicy)
SecurityException's.

* <http://www.physci.org/codes/javafaq.jsp#stacktrace>

 

[John Currier]

Andrew, I can vouch that showDocument() can silently fail with no
indication that anything went wrong. It's a royal pain to debug when
it fails like that.

John

 

[Andrew Thompson]

Andrew, I can vouch that showDocument() can silently fail with no
indication that anything went wrong.

Yes, I am aware of the problem with the showDocument() method*,
but this browser has displayed that it will act on showDocument().
So that is apparently not the problem here.

OTOH, when something in an applet works for an URL but not a file,
it is most often because the applet does not have the necessary
file permissions or, less common, the programmer has mistaken
the server <-> client filesystems.

* <http://www.physci.org/test/showdoc/>

 

[Roland]

Roland wrote:




Thanks, Roland - what you say makes sense; it happens to me in IE,
Netscape and Firefox. It's just that there are no complaints from
either Java or the browser.

Mike.

When you're using Firefox, open the Javascript console (menu Tools ->
JavaScript Console). It may contain an error message like
Security Error: Content at http://yourserver/path/to/YourApplet.html
may not load or link to file:///C:/path/to/your.PDF.

AFAIK, Netscape also has a Javascript console, but for IE I'm don't know
to display this kind of messages.
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \

 

[Andrew Thompson]

..open the Javascript console..

'Javascript'?!? Did I miss something, where did JS come into it?

 

[Roland]

... Your code should be throwing (big, fat, juicy)
SecurityException's.

Really?! I've created an applet and hosted it on a webserver. When it
runs in Firefox and tries to showDocument a file://-URL, nothing seems
to be happening. *Java* neither throws a "big, fat, juicy
SecurityException" nor any other exception. The only message is shown in
the Firefox *Javascript* console (a security error).
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \

 

[Roland]

'Javascript'?!? Did I miss something, where did JS come into it?

"Javascript console", not "Javascript".
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \

 

[Andrew Thompson]

On 2 Jun 2005 13:42:31 -0700, maxmike wrote:

It seems I have missed some important points thus far in this thread.

I have a trusted ..

Missed that extremely important bit! That means the Java
'SecurityExceptions' I have been going on about should not
be happening (just as all have been trying to convince me).
[ Ooops, sorry! ]

Further, I managed to partially replicate the problem, as described
by the OP and reiterated by Roland. But that leads me to further
questions..

..applet that is supposed to generate a pdf file and
save it as a temporary file

So you must possess a File object of this file at one stage, right? [1]

..on the local machine, then display it.
Since display of such an animal can only happen with showDocument(URL,
type) I am trying to build the url using :
URL url = new URL("file:" + File.separator + File.separator +
"filename.pdf");

[ I suspect 'File.separator' is wrong for this context, note that
the separator character for URL's is '/'*, and that is the same
across platforms. * <http://www.gbiv.com/protocols/uri/rfc/rfc3986.html> ]

[1] Why are you not using URL url = tempFile.toURL(); to get the
URL of the file? (..and does that work any better/differently?)

Just how 'temporary' is this temp file to which you wrote the PDF?
If it is closed & all references discarded, it may have been GC'd
by the VM and deleted by the VM/OS.

 

[maxmike]

When you're using Firefox, open the Javascript console (menu Tools ->
JavaScript Console). It may contain an error message like
Security Error: Content at http://yourserver/path/to/YourApplet.html
may not load or link to file:///C:/path/to/your.PDF.

AFAIK, Netscape also has a Javascript console, but for IE I'm don't know
to display this kind of messages.

Roland,

Thanks for this hint - didn't realize there was such a console. I was
relying on the Java console to report errors.
The big thing I forgot to mention is that I can read and write files
from/to the local file system with this applet while connected to the
server IFF I use the file open/saveas dialog. Just can't seem to do it
with showDocument().

Mike.

 

[Andrew Thompson]

"Javascript console", not "Javascript".

I was just surpised to hear the errors appeared in the JS console,
rather than the Java console. (But yes, I am finally clear on that now,
after seeing it for myself - I did a little test of my own using Mozilla,
which uses the fundamentally same engine as both NN and FF).

Interestingly, but veering off topic, I have noticed that Moz.
cannot even tell you it's own version number if JS is disabled.
It sounds as though the common rendering engine of all three is
heavily reliant on using JS behind the scenes.

 

[Mickey Segal]

When you're using Firefox, open the Javascript console (menu Tools ->
JavaScript Console). It may contain an error message

But the JavaScript console does not contain output from non-error
System.out.println methods. Is there some way to get a Java Console in
Firefox other than using the Windows Java Control Panel to display the Java
Console icon all the time?

 

[maxmike]

Andrew Thompson wrote:
\

Further, I managed to partially replicate the problem, as described
by the OP and reiterated by Roland. But that leads me to further
questions..

..applet that is supposed to generate a pdf file and
save it as a temporary file

So you must possess a File object of this file at one stage, right? [1]
Yes.

..on the local machine, then display it.
Since display of such an animal can only happen with showDocument(URL,
type) I am trying to build the url using :
URL url = new URL("file:" + File.separator + File.separator +
"filename.pdf");

[ I suspect 'File.separator' is wrong for this context, note that
the separator character for URL's is '/'*, and that is the same
across platforms. * <http://www.gbiv.com/protocols/uri/rfc/rfc3986.html> ]

Then why don't I get a malformedURLException() ?

[1] Why are you not using URL url = tempFile.toURL(); to get the
URL of the file? (..and does that work any better/differently?)

Just how 'temporary' is this temp file to which you wrote the PDF?
If it is closed & all references discarded, it may have been GC'd
by the VM and deleted by the VM/OS.

I wanted to overwrite the "temp" file (always at the same location) so
the user can just look at the doc and then decide if she wants to save
it.

 

[Roland]

Roland wrote:




Roland,

Thanks for this hint - didn't realize there was such a console. I was
relying on the Java console to report errors.
The big thing I forgot to mention is that I can read and write files
from/to the local file system with this applet while connected to the
server IFF I use the file open/saveas dialog. Just can't seem to do it
with showDocument().

Mike.

By using showDocument(URL), Java hands the display of the URL over to
the browser. The URL leaves the Java security sandbox (with its
restrictions, lifted if you've signed the applet), and enters the
browser's security system. Then it's entirely up to the browser to
determine if it is safe to display it.
I'm not sure, but in IE the Security Zones may affect this (Tools ->
Internet Options -> Security).
In Firefox/Mozilla/Netscape displaying a local filesystem file (a
file://-URL) by a remote server (a http://-URL) is not allowed by
default. FF/Moz/NS have configurable security policies but there's no UI
interface for configuring them (there is an extension, though). I'm not
sure either if it is possible to allow a site accessing a local
filesystem file.
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \

 

[Roland]

But the JavaScript console does not contain output from non-error
System.out.println methods. Is there some way to get a Java Console in
Firefox other than using the Windows Java Control Panel to display the Java
Console icon all the time?

Firefox's Javascript console only displays messages from the browser,
not Java's exceptions or System.out/System.err messages. These are shown
in Java's own console.

There's an extension "Open Java Console" that allows to open the Java
console by a toolbar button, from the Tools menu or by Ctrl+Shift+J.
<http://www.extensionsmirror.nl/index.php?showtopic=317>
[To get the toolbar button, you have to customize your toolbar (View ->
Toolbars -> Customize) and drag the button to your toolbar.]
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \

 

[Andrew Thompson]

I have a trusted applet that is supposed to generate a pdf file and
save it as a temporary file on the local machine, then display it.
Since display of such an animal can only happen with showDocument(URL,
type) ..

Since your applet is trusted, you might invoke a tool
such as BrowserLauncher* to display the PDF file.

* BrowserLauncher determines the default browser and
launches it pointing to any URL you specify.

 

[maxmike]

Since your applet is trusted, you might invoke a tool
such as BrowserLauncher* to display the PDF file.

* BrowserLauncher determines the default browser and
launches it pointing to any URL you specify.

Thanks, Andrew - might give that a try even though people are
complaining about problems with it in some OS's like Win2K.

In my mind - the bottom line on this story is that the browsers seem to
have taken it upon themselves to block local file system acces to
trusted server applets. In other words, they are unaware of the
applet's level of trust. I suppose too much caution is better than
none, but it's a dumb situation that should be fixed.

 

[Andrew Thompson]

On 6 Jun 2005 08:03:27 -0700, maxmike wrote:

(browser change page)

..In other words, they are unaware of the
applet's level of trust.

It is more likely they are beyond caring.

..I suppose too much caution is better than
none, but it's a dumb situation that should be fixed.

It won't. Not unless there is a paradigm shift in the thinking
of the browser makers. Browser makers are much more concerned
with ensuring that 'pop-up' windows never happen than that page
changes can be effected by 'some plug-in', trusted or not.

Personally, I cannot blame them, though it is frustrating
when you are delivering (attempting to deliver) content
the user specifically wants.