File associations / sandboxed app.
http://www.1point1c.org/spacesim/spacesim.jnlp
Points to the launch file for a sandboxed
application (<150 Kb download) that claims
(OK suggests) file associations for two
file types '.sss' (space simulation scenarios)
& '.sso' (space simulation options).
( There are ways to export/create these file types,
but you can get the default '.sss' file here
http://www.1point1c.org/spacesim/spacesim-data.zip )
By claiming the file assocation, the Space Simulator
needs to provide '-open fileName' functionality in the
main(), which it does.
But there is a quirky aspect to it when running
in Java 1.5 - if the user double clicks a '.sss' file,
- they are asked ny the plug-in if they want to
proceed - with the offer to
|_|Do not showthis advisory again
- The user selects that and clicks 'Yes' (open)
- The GUI appears with the file selected.
..But! JWS does notremember that the user
selectedalways allow, and asks them again
(& again, & again..)
Do you want to allowthis action?
Is that defined behaviour for a sandboxed
application?
Do the full privileges applications behave
differently (i.e. remember when the user
selectsalways allow)?
Is it just my system/Java version,
(I'm running Win XP Pro, Java 1.5.0_09)
does it work on other combinations?
Anybody? I would appreciate even test
results from other OS' (besides Windows).
Note that the launch file has moved to here.
http://www.1point1c.org/spacesim/sim/spacesim.jnlp
The data/build file is available here..
http://www.1point1c.org/spacesim/data/
Should I file this as a bug?
I've just tried this using Java 6/WinXP and the behaviour does seem inconsistent but it depends on how you interpret it. Upon dbl clicking the sss data file, I'm prompted with a dialog to allow the app to read the file and I click allow always.
I then get a file chooser where I have to select the file again. Is that part of the app or a webstart problem? Incidently, clicking cancel on this file chooser puts the app in a state where I need to kill it.
Now if I repeat these steps, it still prompts me with the security dialog. At first, I thought it must be a bug in webstart as it ignores my "always allow" setting. But I think the always allow means that webstart will allow the app to open and read the file as many times as the app needs too during the execution of the app, not on subsequent invocations.
..
> ...I'm prompted with a dialog to allow the app to
> read the file and I click allow always.
>
> I then get a file chooser where I have to select the
> file again.
I see that as a separate problem.
Again - I do not know if it is intended behaviour,
but it makes no sense to force the user to identify
the file a second time.
>...Is that part of the app or a webstart
> problem? Incidently, clicking cancel on this file
> chooser puts the app in a state where I need to kill
> it.
Oops! Sorry, I had been meaning to fix that.
> ...But I think the always allow means that
> webstart will allow the app to open and read the file
> as many times as the app needs too during the
> execution of the app, not on subsequent
> invocations.
At first I was sceptical, but a few further tests*
seem to support what you are saying.
* Using the menus within the application that
also open files, after selecting 'remember
my decision', at first file 'double-click open', I
did not get further prompts, though usually
I do.
My investigations are continuing, but here it is
partly complicated by getting different versions
of web-start depending upon whether I double
click the desktop launch icon (1.6), or an
associated file (1.5) - the advisory dialogs
seems different as well.
Thanks, I think you have effectively answered
my question, but I'll mull it over some more..
Perhaps you should sign the application so that you have all permissions. You can use the thawte freemail certificate (google dalloway) if you're concerned about cost. This may solve your problem.
> Perhaps you should sign the application so
> that you have all permissions.
Yeah.. I'd been meaning to try that (though I
want this application to be sandboxed).
I did a quick test just then, and the behaviour
of the (self) signed all-permissions example
(assuming the user chooses 'always trust this
publisher'.. whatever) is the same is the
sand-boxed version, but without the initial
warning.
It's too 'late' now, but when I get up, I'll tidy
up the ant build file, and upload the simple
code/build/JNLP so others can play with it.
> (I will..)> ..upload the simple code/build/JNLP so others can play with it. See "Example of using the JNLP file API" http://forum.java.sun.com/thread.jspa?threadID=5122050
Hi Andrew. Nice example. In the loadFile(String path) method, why do you not have something like this (see below). This way, double clicking on a zzz file will load it straight into the text pane which is the behaviour most users would expect. At the moment, it always prompts the user to reselect the file from the file chooser.
if (path.equals("."))
{
fileContents = fileOpenService.openFileDialog(path, xtns);
// the user may have cancelled the action..
if (fileContents!=null)
{
loadFile( fileContents.getInputStream() );
}
}
else
{
loadFile(new FileInputStream(path));
}
> Hi Andrew. Nice example. In the loadFile(String path)
> method, why do you not have something like this (see
> below).
...if (path.equals("."))
{
....
else
{
loadFile(new FileInputStream(path));
I see what your saying, and that should work
fine for trusted applications, but I must admit
that my main interest (at the moment) is
sandboxed apps., and they only have the JNLP
API classes/methods available.
My real complaint here, is that when the
application has a specific file name,
(and the matter of trust has been settled)
there should be a way to open that file
directly, without further user interaction.
I would imagine the best way to do that is
to alter the FileOpenService.openFileDialog()
to directly return* a FileContents object if
a) the application is trusted and
b) a specific file is requested.
* Without ever showing a file chooser, let alone a
file chooser in which the filename has disappeared
and the suggested file extensions are ignored!
Alternately, the JNLP API should provide a
FileContents constructor that accepts a
String, and either
a) instantiate a FileContents object (if trusted), or..
b) throw an exception/'prompt the user' otherwise.
> Alternately, the JNLP API should provide a
> FileContents constructor that accepts a
> String, and either
> a) instantiate a FileContents object (if trusted), or..
> b) throw an exception/'prompt the user' otherwise.
..and since it does*, this matter is effectively
settled..
JWS 1.5+ offers..
ExtendedService.openFile(File)
We can use it like this..
File f = new File(path);
// 1.5+
FileContents fc = extendedService.openFile(f);
For a sandboxed application, it will mention
the specific file name, and ask the user if it
is OK to open it. If they agree, a FileContents
is returned without any dialogs getting in the
way.
( OK - I should have looked more carefully at
the JavaDocs, in the first place.. ;)
One of the enhancements in javaws 6.0, I believe, is that when launching "javaws -open <filename>" or "javaws -print <filename>" the file READ permission will be granted on that file.
This should remove the extra security dialog if the file is accessed by th app with ExtendedService.openFile(filename);
/Andy
> One of the enhancements in javaws 6.0, I believe, is
> that when launching "javaws -open <filename>" or
> "javaws -print <filename>" the file READ permission
> will be granted on that file.
That is great news! It always seems a bit odd to
be asked if you want to 'give permission' to a file
read for a file you just double clicked in expectation
of the app. openning it.
Unfortunately I am still getting JWS 1.5 for a 1.6 VM.
Can anybody confirm the 'filetest-sandbox.jnlp' *
behaves that way when the user gets JWS 1.6?
Note that to launch it, you simply need to
a) launch the filetest-sandbox.jnlp
b) close the application
c) rename any old txt file as a .zzz file (or create one).
d) double click ithe '.zzz' file.
* You can find launch and build file here..
http://www.physci.org/jws/#fs
