AccessControlException when serving applet using GlassFish v2

Thread view:

Qu0ll - 08 Dec 2007 15:03 GMT

I have an applet which uses RMI to connect to a server and it runs fine when
run through the NetBeans applet viewer. But when I run the HTML page that it
is embedded in with GlassFish I get the following exception:

Exception in thread "Thread-7" java.security.AccessControlException: access
denied (java.net.SocketPermission 10.1.1.3:61946 connect,resolve)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkConnect(Unknown Source)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory$AsyncConnector.<init>(Unknown
Source)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Unknown
Source)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source)
at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source)
at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source)
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at com.qu0ll.Test_Stub.register(Unknown Source)

when the applet first tries to access a server class method via RMI.

The only difference that I can see between the applet viewer environment and
the GlassFish environment is that in NetBeans I can specify an applet.policy
file to run with when using the applet viewer.

So how can I specify an applet.policy file for running an applet through
GlassFish? Or is this problem not related to the applet.policy file at all?

Signature

And loving it,

-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

Reply to this Message

Arne Vajhøj - 08 Dec 2007 15:17 GMT

> I have an applet which uses RMI to connect to a server and it runs fine
> when run through the NetBeans applet viewer. But when I run the HTML
[quoted text clipped - 3 lines]
> access denied (java.net.SocketPermission 10.1.1.3:61946 connect,resolve)
> at java.security.AccessControlContext.checkPermission(Unknown Source)

I think this can be translated to: an applet downloaded from another
IP address than 10.1.1.3 tried to connect to 10.1.1.3 and was correctly
blocked by applet security.

Arne

Reply to this Message

Qu0ll - 08 Dec 2007 21:41 GMT

>> I have an applet which uses RMI to connect to a server and it runs fine
>> when run through the NetBeans applet viewer. But when I run the HTML page
[quoted text clipped - 7 lines]
> IP address than 10.1.1.3 tried to connect to 10.1.1.3 and was correctly
> blocked by applet security.

I don't think that is correct as I am trying to run the applet on 10.1.1.3
and it is served on 10.1.1.3 (the same machine). Why would it object to me
connecting to the same machine on which it is served?

Signature

And loving it,

-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

Reply to this Message

Lew - 08 Dec 2007 21:46 GMT

"Arne Vajhøj" wrote:

>> I think this can be translated to: an applet downloaded from another
>> IP address than 10.1.1.3 tried to connect to 10.1.1.3 and was correctly
>> blocked by applet security.

> I don't think that is correct as I am trying to run the applet on
> 10.1.1.3 and it is served on 10.1.1.3 (the same machine). Why would it
> object to me connecting to the same machine on which it is served?

If you're running it on the same machine, perhaps it thinks it's running from
127.0.0.1. What is the host of the web page that holds the applet, as seen in
the browser address bar?

Signature

Lew

Reply to this Message

Qu0ll - 08 Dec 2007 23:04 GMT

> If you're running it on the same machine, perhaps it thinks it's running
> from 127.0.0.1. What is the host of the web page that holds the applet,
> as seen in the browser address bar?

Yes, I think you are right. I changed the URL to access the machine name
and it loads correctly.

However, now I have another problem. Certain RMI callbacks are resulting
in:

java.rmi.UnmarshalException: Error unmarshaling return header; nested
exception is:
java.net.SocketException: Connection reset
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:209)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at com.qu0ll.TestApplet_Stub.render(Unknown Source)
at com.qu0ll.TestServer.handleMouseMove(TestServer.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

The line in question is calling a method in the applet from the server that
is called in other places without any exceptions. Why would the connection
be reset in this case? What does it mean anyway exactly?

Signature

And loving it,

-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

Reply to this Message

Arne Vajhøj - 08 Dec 2007 22:06 GMT

> "Arne Vajhøj" <arne@vajhoej.dk> wrote in message
>> I think this can be translated to: an applet downloaded from another
[quoted text clipped - 4 lines]
> 10.1.1.3 and it is served on 10.1.1.3 (the same machine). Why would it
> object to me connecting to the same machine on which it is served?

That is what the exception says.

Try and display getCodeBase() in the applet and see whether
it really contains 10.1.1.3 !

Arne

Reply to this Message

Andrew Thompson - 08 Dec 2007 15:34 GMT

>I have an applet which uses RMI to connect to a server and it runs fine when
>run through the NetBeans applet viewer. But when I run the HTML page that it
>is embedded in with GlassFish I get the following exception:
>
>Exception in thread "Thread-7" java.security.AccessControlException: access

...

>The only difference that I can see between the applet viewer environment and
>the GlassFish environment is that in NetBeans I can specify an applet.policy
>file to run with when using the applet viewer.

That is a kludgy way for Netbeans to 'gloss over' the detail
that applets require full trust for this operation.

>So how can I specify an applet.policy file for running an applet through
>GlassFish? Or is this problem not related to the applet.policy file at all?

Changing ploicy files is not a viable option for a 'real world'
deployment.

The best strategy is that the applet needs to be signed.

The Java Plug-In will then prompt the user if they want to
accept the signed code, and if the user decides (and is
given the chance to decide*) to trust it, the applet will
be able to do that without throwing an ACE.

* Some Java installs can be configured (e.g. by SysAdmin)
to refuse acceptance of signed code, or refuse code signed
with an 'uncertified (e.g. home made) certificate'.

( I am not sure of the JWS reaction to cross-domain RMI.
For cross-domain *URL access*, you can leave the project
sandboxed and unsigned, and the user will be prompted
on first access. )

Signature

Andrew Thompson
http://www.physci.org/

Reply to this Message

Qu0ll - 08 Dec 2007 21:43 GMT

>>I have an applet which uses RMI to connect to a server and it runs fine
>>when
[quoted text clipped - 36 lines]
> sandboxed and unsigned, and the user will be prompted
> on first access. )

Why would the applet need to be signed to access the server from which it is
downloaded? I thought that was OK as far as applet security goes or are you
saying that it's a different kettle of fish for RMI?

Signature

And loving it,

-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

Reply to this Message

AccessControlException when serving applet using GlassFish v2

Free Magazines