users@glassfish.java.net

Re: AppClient/JWS/Derby/Security problems

From: Tim Quinn <Timothy.Quinn_at_Sun.COM>
Date: Fri, 08 Sep 2006 15:00:16 -0500

Martin, Ray wrote:
> In 'appclient only' and appclient/JWS, i am running into errors before
> getting to appreciate whether or not DBHome has been effective.
>
> If one should not pass parameters to let appclient/JWS know where the user
> policy is located, what is the appropriate mechanism to set security
> parameters? Where is the policy that appclient/JWS is using? is it
> available to me, an end-user, so that i can define application security
> parameters?
>
A bit of background, for those on the mailing list who might be new to
app clients on GlassFish... When you deploy an app client JAR or an EAR
that contains at least one app client, GlassFish creates a generated app
client JAR. This file contains contents of the developer's app client
plus possibly some additional files. This is the JAR file that the
deploy --retrieve option and the separate get-client-stubs asadmin
commands download.

For Java Web Start launches of an app client, GlassFish automatically
signs the generated app client JAR if the administrator has not signed
it manually after GlassFish has generated it. (See
http://blogs.sun.com/quinn/entry/signing_the_glassfish_java_web for some
more about this.) Either way, the downloaded app client JAR is signed.
The JNLP that GlassFish generates requests that the app client code be
granted full permissions. The Java Web Start code on the client system
detects this, makes sure the JAR has been signed, and then displays
information about the cert that was used to sign the JAR and asks the
user whether he or she wants to trust that code. Assuming the user
agrees, the download proceeds and Java Web Start grants full permissions
to that code. We adopted this approach so that users can make the
conscious choice about whether to trust downloaded code or not. The
level of granularity with which permissions are granted is a
characteristic of Java Web Start. GlassFish just uses that mechanism.

The end result is that the client code should have all permissions...if
the user has agreed to trust the code.

I know you've described in this thread several issues you've encountered
in a variety of experiments. Can you reiterate which error you are
encountering now? Is it still the null emf?

- Tim
> -----Original Message-----
> From: Timothy.Quinn_at_Sun.COM [mailto:Timothy.Quinn_at_Sun.COM]
> Sent: Friday, September 08, 2006 2:47 PM
> To: users_at_glassfish.dev.java.net
> Subject: Re: AppClient/JWS/Derby/Security problems
>
>
> Hi, again, Ray.
>
> Note that the Java Web Start-launched app client container no longer
> honors the policy setting option you have been specifying on the URL.
> This was determined to be a security risk because code from an arbitrary
> source could try to grant itself elevated permissions this way.
>
> As for setting DBHome... You should be able to add to the query string
> in the URL something like this
>
> prop=DBHome=correctValue
>
> separated using an ampersand ('&') from any other argument or property
> settings in the query string. This blog entry
>
> http://blogs.sun.com/quinn/entry/command_line_arguments_and_properties
>
> has more details.
>
> Could you try that and see if it gets you farther?
>
> - Tim
>
> Martin, Ray wrote:
>
>> Because i am not able to get appclient/JWS to 'play nice' with my security
>> policy, i commented out code that causes a SecurityManager to be required.
>> i took out all the getClassLoader calls - they were just for learning
>> experience. i commented out all setProperty methods - now i cannot set
>> DBHome - not a good thing.
>>
>> So, now i am back to seeing how well appclient/JWS will run my
>>
> application.
>
>> It keeps coughing up the error, javax.persistence.PersistenceException: No
>> Persistence provider for EntityManager named SVG_drawings. This raises
>>
> the
>
>> question of why appclient/JWS cannot see META-INF/persistence.xml in my
>> application jar file - while on the other hand, 'appclient only' fails on
>> the same line (the creation of EntityManagerFactory), but the error report
>> is totally different - 'appclient only' kicks out the
>>
> currentLoaderNotValid
>
>> error.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>