AccessControlException when serving applet using GlassFish v2
Qu0ll
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?
--
And loving it,
-Q
_________________________________________________
Qu0llS...@gmail.com
(Replace the "SixFour" with numbers to email me)
Arne Vajhøj
> 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)
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
Andrew Thompson
>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. )
--
Andrew Thompson
http://www.physci.org/
Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200712/1
Qu0ll
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?
Qu0ll
news:475ab58b$0$90272$1472...@news.sunsite.dk...
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?
Lew
>> 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.
Qu0ll wrote:
> 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?
--
Lew
Arne Vajhøj
>> 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?
That is what the exception says.
Try and display getCodeBase() in the applet and see whether
it really contains 10.1.1.3 !
Arne
Qu0ll
news:noGdnSeLNsxTjcba...@comcast.com...
> 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?