Access to local files with signed applet in Vista/IE7

H

Hansi

Hi there.

I heard, that with Vista it will no longer be possible to access files
from an applet even if it is signed.

I use an applet as a helper application for down- and uploading multiple
files in several web-applications. Of course it is signed.

Is there any workaround?
Is there any hope, my applets will be able to access local files?

PS: It is not enough to access files within the ie-sandbox, because the
downloaded files must be in a folder, that is accessible to other
applications (like word, excel) to be edited immediately.


Can it be true that these applets cannot be used anymore?
Can it be true that microsoft invented another annoying and useless
"security"-feature that keeps us from working?????

Any help and any idea wolud be appreciated.

Regards

Hans
 
A

Andrew Thompson

Hansi wrote:
....
I heard, that with Vista it will no longer be possible to access files
from an applet even if it is signed.

I heard that too. Maybe it was the same place
you heard it. Care to share, where?
I use an applet as a helper application for down- and uploading multiple
files in several web-applications. Of course it is signed.

Is there any workaround?

Java Web Start. (less of a work-around, more
of a 'new' paradigm.)

Examples...
Is there any hope, my applets will be able to access local files?

...<http://www.physci.org/jws/#fs>
Even a sandoxed JWS applet can access local
files using the JNLP API's FileOpenService and
FileSaveService.

Andrew T.
 
H

Hansi

Hi Andrew,

I do not understnad the whole thing.

Microsoft secures applets to deny any local access, even when signed.

Sun builds a new api to allow local access (even if unsigned??)

Where is the security?
May applets do anything with this crazy api?

Why did java invent some objects again?
(I cannot use the JNLP Methods, because I need a file-dialog with
multi-file selection, and I cannot use the File-Read and File-Write methods,
because I would have to write anything again....


Any background info??

Regards Hansi
 
A

Andrew Thompson

Hansi said:
Hi Andrew,

Hi. Please refrain from top-posting.
I find it most confusing. Instead, break in
wherever you have a comment.

I'll show you..
I do not understnad the whole thing.

It is a complicated area, with a lot of history.
Microsoft secures applets to deny any local access, even when signed.

(block moved)
Sun builds a new api to allow local access (even if unsigned??)

It is *not* new. Web start was avialable as a separate
plug-in from around late 1.1, was 'cobundled' along
with 1.2/1.3, and integrated with the normal Java install
as of Java 1.4.2 (from memory).
Where is the security?
May applets do anything with this crazy api?

Did you try the examples, from the page I linked to?

Again, that example is here..
The '.jnlp' file launches the application(s).
The 'sandbox'ed one is most relevant.
<http://www.physci.org/jws/filetest-sandbox.jnlp>

I can assure you of the following, about the examples.
- I wrote them.
- They are coming off my own domain/site (PhySci).
- They are safe (barring bugs on my part,
or bugs in the JRE).
- If you have ant, and a few minutes, you
can download the .zip & compile and build
them from the source, and see them running
on a 'sandboxed' computer.

Why did I mention all that?

Because I do not think you tried my examples,
which explain, on-screen, better than words
can, how the JNLP API allows safe access to
files, from a web-start application.

So, if you have some valid reason not to try the
examples, please mention it. Otherwise, please
save yourself, and everyone else, some time by
trying the sandboxed file service example, as a
launched application.

Report back your results (for further discussion).

Andrew T.
 
M

Mickey Segal

Andrew Thompson said:
Hansi wrote:
...

I heard that too. Maybe it was the same place
you heard it. Care to share, where?

At http://weblogs.java.net/blog/chet/archive/2006/10/java_on_vista_y.html I
see:
"Problem : Java Web Start and Java Control Panel run as standalone
processes, and therefore have no trouble reading and writing to necessary
places on disk (such as the usual deployment directory). Java Plug-in,
however, could not access these directories, and would thus end up writing
to a new virtualized location on disk which could not be seen by these other
applications. We could no longer share the information between these very
related applications. It was also not clear whether the virtualized
directory used by Plug-in would actually be persistent; there was no
guarantee that these virtualized locations were permanent.
Solution: Later releases of Vista provide a persistent directory that all
processes can reach. The directory is within the sandboxed area that the
IE7 browser can write to, so the overall filesystem is still protected, but
as long as other non-IE7 processes (such as Java Web Start and the Java
Control Panel) can reach this location, we have the sharing we need. We
chose this directory to house our deployment directory so that all of our
Java deployment components could use and share it effectively."

Does anyone have more information? How does one specify this persistent
directory? Can the user examine those files later if needed? Does this
only affect IE7 or also Firefox?
 
M

Mickey Segal

Mickey Segal said:
Does anyone have more information? How does one specify this persistent
directory? Can the user examine those files later if needed? Does this
only affect IE7 or also Firefox?

There is a bug report at:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6396594
listed as "fixed" describing how one is allowed to write to a folder of the
form:
c:\Users\ngthomas\AppData\Local\Microsoft\Windows\Temporary Internet
Files\Virtualized
but it is not clear if this is where one should be writing to save non-cache
files and it is not clear how one determines the Windows user name or some
other indication of where one should be writing files.

Since Vista is being let loose today it is important to get this information
available. Has Sun or anyone else written a guide for dealing with this
change, other than encouraging users to use some environment other than
Internet Explorer 7 on Windows Vista?
 
M

Mickey Segal

Mickey Segal said:
There is a bug report at:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6396594
listed as "fixed" describing how one is allowed to write to a folder of
the form:
c:\Users\ngthomas\AppData\Local\Microsoft\Windows\Temporary Internet
Files\Virtualized
but it is not clear if this is where one should be writing to save
non-cache files and it is not clear how one determines the Windows user
name or some other indication of where one should be writing files.

Since Vista is being let loose today it is important to get this
information available. Has Sun or anyone else written a guide for dealing
with this change, other than encouraging users to use some environment
other than Internet Explorer 7 on Windows Vista?

Several Java Vista file writing bug reports at Sun point to:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6443366
which notes that:
"the deployment wiki page:
http://j2se.sfbay. xxxxx .com/web/bin/view/JCG/DeploymentInVista
contains a section in the bottom containing Release Notes that need to be
added specifically for the Vista platform."

The URL seems to be a nominal one but I can't figure out the real one.
 
M

Mickey Segal

I've gotten some local file writing working for signed applets on Vista.
Here are the details:

In Vista, Microsoft has clamped down on file writing from browsers, as
detailed at:
http://msdn.microsoft.com/library/d...ry/en-us/IETechCol/dnwebgen/ProtectedMode.asp

If the signed applet tries to write a file to an arbitrary location,
Internet Explorer 7 considers this an error. From Netscape, the file
writing is allowed, but a file that was directed to be written at
c:\foldername is re-routed instead to
c:\Users\theirUserName\AppData\Local\VirtualStore\foldername.

A workaround is to choose the location
c:\Users\theirUserName\AppData\LocalLow\foldername instead. From both
Netscape and IE7, file writing is allowed here and no re-routing to a
virtual folder is done. The Java System property user.home gives you the
needed information about the relevant drive and user name.

For those who want the ability to write files more generally, there is some
information in the Microsoft URL above and apparently Sun could make this
happen through modifications on its end, as detailed at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6504236. As Andrew
Thompson indicated, another solution is Java Web Start, but the LocalLow
procedure outlined above may be the form most likely to be allowed on many
networks.
 
V

vamsi

I've gotten some local file writing working for signed applets on Vista.
Here are the details:

In Vista, Microsoft has clamped down on file writing from browsers, as
detailed at:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETe...

If the signed applet tries to write a file to an arbitrary location,
Internet Explorer 7 considers this an error. From Netscape, the file
writing is allowed, but a file that was directed to be written at
c:\foldername is re-routed instead to
c:\Users\theirUserName\AppData\Local\VirtualStore\foldername.

A workaround is to choose the location
c:\Users\theirUserName\AppData\LocalLow\foldername instead. From both
Netscape and IE7, file writing is allowed here and no re-routing to a
virtual folder is done. The Java System property user.home gives you the
needed information about the relevant drive and user name.

For those who want the ability to write files more generally, there is some
information in the Microsoft URL above and apparently Sun could make this
happen through modifications on its end, as detailed athttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6504236. As Andrew
Thompson indicated, another solution is Java Web Start, but the LocalLow
procedure outlined above may be the form most likely to be allowed on many
networks.



HI all,

Please let me know how even a sample applet can be run from Vista. I
am unable to run a sample applet from Vista IE7.

Please give me some sample code.

Regards,
Vamsi.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,968
Messages
2,570,153
Members
46,701
Latest member
XavierQ83

Latest Threads

Top