«

I've been writing an application to run under jnlp/Java Web Start, and
have mostly been making do with the restrictions of running under a
sandbox. Some users might want the safer "sandbox" version but others
might want more features that require allpermissions. Is there a way
for the application to detect which way it was run?

All I can think of is to name different main classes in each of two
different .jnlp files.

David Lamb wrote:
> I've been writing an application to run under jnlp/Java Web Start, and
> have mostly been making do with the restrictions of running under a
> sandbox. Some users might want the safer "sandbox" version but others
> might want more features that require allpermissions. Is there a way
> for the application to detect which way it was run?
>
> All I can think of is to name different main classes in each of two
> different .jnlp files.

Check out
http://java.sun.com/javase/6/docs/ap...tyManager.html
If your only choices are sandbox and allpermissions, you can simply
check whether you have permission to do any single thing that would be
illegal in the sandbox, and that will tell you everything.

--
Cheers,
Alan (San Jose, California, USA)

Alan Malloy wrote:
> David Lamb wrote:
>> Is there a way for the application to detect which way it was run?
> Check out
> http://java.sun.com/javase/6/docs/ap...tyManager.html
> If your only choices are sandbox and allpermissions, you can simply
> check whether you have permission to do any single thing that would be
> illegal in the sandbox

Thanks! It looks like
http://java.sun.com/javase/6/docs/te...ertyPermission
would work best for me, since that tells me whether I can read
properties like user.home.

You seem to be suggesting it is wise to plan for an intermediate level
of permissions between just sandbox and allpermissions. Is it common to
do that, or do most people just go for allpremissions if sandbox is
unacceptable?

David Lamb wrote:
> Alan Malloy wrote:
>> David Lamb wrote:
>>> Is there a way for the application to detect which way it was run?
>> Check out
>> http://java.sun.com/javase/6/docs/ap...tyManager.html
>> If your only choices are sandbox and allpermissions, you can simply
>> check whether you have permission to do any single thing that would be
>> illegal in the sandbox
>
> Thanks! It looks like
> http://java.sun.com/javase/6/docs/te...ertyPermission
>
> would work best for me, since that tells me whether I can read
> properties like user.home.
>
> You seem to be suggesting it is wise to plan for an intermediate level
> of permissions between just sandbox and allpermissions. Is it common to
> do that, or do most people just go for allpremissions if sandbox is
> unacceptable?

I think many people do go for allpermissions, but it's not the best
strategy if you're hoping for people who don't implicitly trust you or
your company to download and run your program. Imagine your end user
loads up your JNLP file and is presented with a dialog. Is he more
likely to use your program if it says "this program needs permission to
connect to the Internet, and read/write to one particular file" or if it
says "this program needs permission to do anything it wants with your
computer"?

--
Cheers,
Alan (San Jose, California, USA)

Alan Malloy wrote:
> David Lamb wrote:
>> You seem to be suggesting it is wise to plan for an intermediate level
>> of permissions between just sandbox and allpermissions. Is it common
>> to do that, or do most people just go for allpremissions if sandbox is
>> unacceptable?
>
> I think many people do go for allpermissions, but it's not the best
> strategy if you're hoping for people who don't implicitly trust you or
> your company to download and run your program.

The only documentation I could find on the <security> element in .jnlp
files (for Java 1.6)only mentions allpermissions.
http://java.sun.com/javase/6/docs/te....html#security
Are there other elements that can go there, and, if so, where do I find
out what they are?

David Lamb wrote:
> Alan Malloy wrote:
>> David Lamb wrote:
>>> You seem to be suggesting it is wise to plan for an intermediate
>>> level of permissions between just sandbox and allpermissions. Is it
>>> common to do that, or do most people just go for allpremissions if
>>> sandbox is unacceptable?
>>
>> I think many people do go for allpermissions, but it's not the best
>> strategy if you're hoping for people who don't implicitly trust you or
>> your company to download and run your program.
>
> The only documentation I could find on the <security> element in .jnlp
> files (for Java 1.6)only mentions allpermissions.
> http://java.sun.com/javase/6/docs/te....html#security
>
> Are there other elements that can go there, and, if so, where do I find
> out what they are?
>
>
>

I confess I haven't done this since college, and while I remember
writing a JNLP file that had specific permissions, I can't find any
evidence online that such a thing exists, so I could be wrong. At any
rate, it sounds like all-permissions still asks the user for
confirmation before each "dangerous" operation, so there doesn't seem to
be any harm in using it.

--
Cheers,
Alan (San Jose, California, USA)

On Mar 28, 11:01*am, David Lamb <dal...@cs.queensu.ca> wrote:
> Alan Malloy wrote:
> > David Lamb wrote:
> >> You seem to be suggesting it is wise to plan for an intermediate level
> >> of permissions between just sandbox and allpermissions. *Is it common
> >> to do that, or do most people just go for allpremissions if sandbox is
> >> unacceptable?
>
> > I think many people do go for allpermissions, but it's not the best
> > strategy if you're hoping for people who don't implicitly trust you or
> > your company to download and run your program.
>
> The only documentation I could find on the <security> element in .jnlp
> files (for Java 1.6)only mentions allpermissions.http://java.sun.com/javase/6/docs/te...ws/developersg...

The developers guide is a good overview, but for the
low down details on JNLP, download the spec. I asked
a member of the Sun deployment team if they could make
the entire spec. web browsable on their site, but the
reply was WTE "No, because of 'licensing'".

<http://java.sun.com/javase/technolog...tart/download-
spec.html>

> Are there other elements that can go there, ..

The oddly named 'j2ee-application-client-permissions'.

That gets unprompted access to the JNLP API services
for the FileOpen/SaveService, the ExtendedService,
the PrintService.. (I think that is it). And the window
warning/banner is removed.

The JACP permissions are rarely used, but handy for
those cases where they are the only extended permissions
that might be of use to an app.

Note that I offer JaNeLA* to validate the launch
files and other resources of JWS based launches.
I mention this because you used the term 'allpermissions'
twice above (one time incorrectly spelt). There is
no such security level.

* <http://pscode.org/janela>

Alternately, if you can 'read' an XSD, you might
go directly to the XSD used by JaNeLA to find what
is allowable.
<http://pscode.org/JNLP-6.0.xsd>

--
Andrew T.
pscode.org

On Sat, 27 Mar 2010 15:11:17 -0700, Alan Malloy
<> wrote, quoted or indirectly quoted someone
who said :

>I think many people do go for allpermissions, but it's not the best
>strategy if you're hoping for people who don't implicitly trust you or
>your company to download and run your program. Imagine your end user
>loads up your JNLP file and is presented with a dialog. Is he more
>likely to use your program if it says "this program needs permission to
>connect to the Internet, and read/write to one particular file" or if it
>says "this program needs permission to do anything it wants with your
>computer"?

Oddly the answer to that question depends on your audience. Some
people won't give permission to something they cannot understand. It
sounds worse that "anything". The author is clearly trying to snow
them.
--
Roedy Green Canadian Mind Products
http://mindprod.com

If you tell a computer the same fact in more than one place, unless you have an automated mechanism to ensure they stay in sync, the versions of the fact will eventually get out of sync.