You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by William Billingsley <wh...@cam.ac.uk> on 2003/06/04 14:18:16 UTC
applet AccessControlException loading Rhino (js.jar is in archive)
I'm using Batik in a couple of applets I'm developing (
http://www.cl.cam.ac.uk/~whb21/svgDraw/svgCircuit.html is one example; the
applet is near the foot of the page)
At startup an AccessControlException occurs when Batik tries to create a
Rhino Interpreter from the InterpreterPool (exception trace at foot of
email). js.jar is included in the archive attribute for the applet on the
page, and is available in the same directory as the applet.
>From what I can see delving into the code, RhinoClassLoader specifically
extends URLClassLoader, so I'm not sure if this a "can't find the class on
the server and not allowed to look elsewhere" (as if I had not included
js.jar) or if this exception is coming straight out of the way Batik is
written, and will always produce this error if the applet is unsigned?
So I have a few questions:
1. How to stop this error (without signing or self-signing the applet --
self-signing will happen eventually but can't yet) .
2. Is there any way of turning ECMAScript off altogether in the document
(but keeping the document "dynamic" so DOM updates made from my applet code
will occur appropriately). In other words, is there a way to avoid
including the 580k js.jar in the archive for the applet?
3. If I did switch it off, is there an easy way to attach onClick and
onDrag events to the SVG elements, to fire directly to Java (without going
through Javascript) [I'm sure there must be but for some daft reason I
can't find it]
Will.
exception trace:
java.security.AccessControlException: access denied
(java.lang.RuntimePermission createClassLoader)
at java.securitiy.AccessControlContext.checkPermission
at java.securitiy.AccessController.checkPermission
at java.lang.SecurityManager.checkPermission
at java.lang.SecurityManager.checkCreateClassLoader
at java.lang.ClassLoader.<init>
at java.security.SecureClassLoader.<init>
at java.net.URLClassLoader.<init>
at org.apache.batik.script.rhino.RhinoClassLoader.<init>
at org.apache.batik.script.rhino.RhinoInterpreter.<init>
at org.apache.batik.script.rhino.RhinoInterpreterFactory.createInterpreter
at org.apache.batik.bridge.BridgeContext.getInterpreter
at org.apache.batik.BaseScriptingEnvironment.dispatchSVGLoadEvent
etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: applet AccessControlException loading Rhino (js.jar is in archive)
Posted by josh <jo...@speakeasy.net>.
William Billingsley wrote:
> I'm using Batik in a couple of applets I'm developing (
> http://www.cl.cam.ac.uk/~whb21/svgDraw/svgCircuit.html is one example; the
> applet is near the foot of the page)
>
> At startup an AccessControlException occurs when Batik tries to create a
> Rhino Interpreter from the InterpreterPool (exception trace at foot of
> email). js.jar is included in the archive attribute for the applet on the
> page, and is available in the same directory as the applet.
>>>From what I can see delving into the code, RhinoClassLoader specifically
> extends URLClassLoader, so I'm not sure if this a "can't find the class on
> the server and not allowed to look elsewhere" (as if I had not included
> js.jar) or if this exception is coming straight out of the way Batik is
> written, and will always produce this error if the applet is unsigned?
I had what sounds like the same problem using Rhino in an unrelated project.
The problem is that Rhino tries to 'compile' some of the functions from
javascript into java as an optimization, and load it via a custom
ClassLoader. There is supposed to be a resource setting somewhere that
controls the optimization behavior, but I couldn't make it work. My
solution? Remove all the classes in org.mozilla.javascript.optimizer
packages from js.jar.
Hope this helps,
- josh
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: applet AccessControlException loading Rhino (js.jar is in archive)
Posted by Vincent Hardy <vi...@sun.com>.
Hi William,
The exception happens because js.jar does not have the
"createClassLoader" permission.
The RhinoClassLoader is really used for two purposes:
a. It is used by Rhino to load classes it dynamically creates.
b. It is used to define the security domain for Rhino. This is used for
some special operations (getURL/parseXML).
You have two options: either you configure Rhino to disable dynamic
class compilation or you need to grant rhino permissions to do that (and
Batik so that you do not get into restrictions due to Rhino being
invoked from Batik).
What Thomas suggest would result in a NullPointerException as you need
to configure Rhino to disable dynamnic class creation / loading.
However, the part regarding the getAccessControlContext seems right.
The security permissions are application-wide settings. If you run
squiggle, you actually use a specific security setting (see
resources/org/apache/batik/apps/resources/svgbrowser.policy). Same for
the rasterizer. In your applet, you also need to set/define the security
settings.
My suggestion is to either grant the 'right' permissions to js.jar in
your applet or you need to disable class compilation in the code. I am
not familiar enough with Rhino to tell you how to do this exactly. There
was a suggestion that removing some classes from js.jar would work.
I hope this helps,
Vincent.
Thomas' suggestion might work even though
Thomas E Deweese wrote:
>>>>>>"WB" == William Billingsley <wh...@cam.ac.uk> writes:
>>>>>>
>>>>>>
>
>WB> I'm using Batik in a couple of applets I'm developing (
>WB> http://www.cl.cam.ac.uk/~whb21/svgDraw/svgCircuit.html is one
>WB> example; the applet is near the foot of the page)
>
>WB> At startup an AccessControlException occurs when Batik tries to
>WB> create a Rhino Interpreter from the InterpreterPool (exception
>WB> trace at foot of email). js.jar is included in the archive
>WB> attribute for the applet on the page, and is available in the same
>WB> directory as the applet.
>
>WB> From what I can see delving into the code, RhinoClassLoader
>WB> specifically extends URLClassLoader, so I'm not sure if this a
>WB> "can't find the class on the server and not allowed to look
>WB> elsewhere" (as if I had not included js.jar) or if this exception
>WB> is coming straight out of the way Batik is written, and will
>WB> always produce this error if the applet is unsigned?
>
> This is the case, currently as written you will always produce
>this error.
>
>WB> So I have a few questions: 1. How to stop this error (without
>WB> signing or self-signing the applet -- self-signing will happen
>WB> eventually but can't yet) .
>
> I took a quick look at the code in Batik, and I think this is
>fairly easy to deal with.
>
> 1) Put the creation of the RhinoClassLoader in a try block. If you
> catch an error make sure rhinoClassLoader the member is null.
>
> 2) In getAccessControlContext if rhinoClassLoader is null.
> return 'java.security.AccessController.getContext()' instead.
>
> The other two places where rhinoClassLoader is used should be
> ok with a null value being passed.
>
> The net effect of this is that Batik will attempt to create a
>protection domain for Rhino (a sandbox for JavaScript to run in) if
>this fails then Rhino will simply run with Batik's permissions. I
>think this is the perfect solution - if Batik is in a sandbox already
>then so is Rhino, if Batik has full permissions Rhino get's a sandbox
>defined by Batik. If someone has granted Batik extra permissions then
>they can choose to also grant Batik classloader permission (in which
>case Rhino get's a sandbox) or let Rhino have those additional
>permissions as well.
>
> Vincent you did the security work does the above sound like it
>might work?
>
>WB> 2. Is there any way of turning ECMAScript off altogether in the
>WB> document (but keeping the document "dynamic" so DOM updates made
>WB> from my applet code will occur appropriately). In other words, is
>WB> there a way to avoid including the 580k js.jar in the archive for
>WB> the applet?
>
> Theoretically yes. I think if you omit the classes from the
>script/rhino directory from the classpath it will not register a
>handler for text/ecmascript. I've never done this and I don't think I
>know anyone who has - but it looks like it should work.
>
>WB> 3. If I did switch it off, is there an easy way to attach onClick
>WB> and onDrag events to the SVG elements, to fire directly to Java
>WB> (without going through Javascript) [I'm sure there must be but for
>WB> some daft reason I can't find it]
>
> Yes, attach listeners to the DOM in Java.
>
>WB> Will.
>
>WB> exception trace: java.security.AccessControlException: access
>WB> denied (java.lang.RuntimePermission createClassLoader) at
>WB> java.securitiy.AccessControlContext.checkPermission at
>WB> java.securitiy.AccessController.checkPermission at
>WB> java.lang.SecurityManager.checkPermission at
>WB> java.lang.SecurityManager.checkCreateClassLoader at
>WB> java.lang.ClassLoader.<init> at
>WB> java.security.SecureClassLoader.<init> at
>WB> java.net.URLClassLoader.<init> at
>WB> org.apache.batik.script.rhino.RhinoClassLoader.<init> at
>WB> org.apache.batik.script.rhino.RhinoInterpreter.<init> at
>WB> org.apache.batik.script.rhino.RhinoInterpreterFactory.createInterpreter
>WB> at org.apache.batik.bridge.BridgeContext.getInterpreter at
>WB> org.apache.batik.BaseScriptingEnvironment.dispatchSVGLoadEvent
>WB> etc.
>
>
>WB> ---------------------------------------------------------------------
>WB> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
>WB> additional commands, e-mail: batik-users-help@xml.apache.org
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
>For additional commands, e-mail: batik-users-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
RE: applet AccessControlException loading Rhino (js.jar is in archive)
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "WB" == William Billingsley <wh...@cam.ac.uk> writes:
WB> I'm using Batik in a couple of applets I'm developing (
WB> http://www.cl.cam.ac.uk/~whb21/svgDraw/svgCircuit.html is one
WB> example; the applet is near the foot of the page)
WB> At startup an AccessControlException occurs when Batik tries to
WB> create a Rhino Interpreter from the InterpreterPool (exception
WB> trace at foot of email). js.jar is included in the archive
WB> attribute for the applet on the page, and is available in the same
WB> directory as the applet.
WB> From what I can see delving into the code, RhinoClassLoader
WB> specifically extends URLClassLoader, so I'm not sure if this a
WB> "can't find the class on the server and not allowed to look
WB> elsewhere" (as if I had not included js.jar) or if this exception
WB> is coming straight out of the way Batik is written, and will
WB> always produce this error if the applet is unsigned?
This is the case, currently as written you will always produce
this error.
WB> So I have a few questions: 1. How to stop this error (without
WB> signing or self-signing the applet -- self-signing will happen
WB> eventually but can't yet) .
I took a quick look at the code in Batik, and I think this is
fairly easy to deal with.
1) Put the creation of the RhinoClassLoader in a try block. If you
catch an error make sure rhinoClassLoader the member is null.
2) In getAccessControlContext if rhinoClassLoader is null.
return 'java.security.AccessController.getContext()' instead.
The other two places where rhinoClassLoader is used should be
ok with a null value being passed.
The net effect of this is that Batik will attempt to create a
protection domain for Rhino (a sandbox for JavaScript to run in) if
this fails then Rhino will simply run with Batik's permissions. I
think this is the perfect solution - if Batik is in a sandbox already
then so is Rhino, if Batik has full permissions Rhino get's a sandbox
defined by Batik. If someone has granted Batik extra permissions then
they can choose to also grant Batik classloader permission (in which
case Rhino get's a sandbox) or let Rhino have those additional
permissions as well.
Vincent you did the security work does the above sound like it
might work?
WB> 2. Is there any way of turning ECMAScript off altogether in the
WB> document (but keeping the document "dynamic" so DOM updates made
WB> from my applet code will occur appropriately). In other words, is
WB> there a way to avoid including the 580k js.jar in the archive for
WB> the applet?
Theoretically yes. I think if you omit the classes from the
script/rhino directory from the classpath it will not register a
handler for text/ecmascript. I've never done this and I don't think I
know anyone who has - but it looks like it should work.
WB> 3. If I did switch it off, is there an easy way to attach onClick
WB> and onDrag events to the SVG elements, to fire directly to Java
WB> (without going through Javascript) [I'm sure there must be but for
WB> some daft reason I can't find it]
Yes, attach listeners to the DOM in Java.
WB> Will.
WB> exception trace: java.security.AccessControlException: access
WB> denied (java.lang.RuntimePermission createClassLoader) at
WB> java.securitiy.AccessControlContext.checkPermission at
WB> java.securitiy.AccessController.checkPermission at
WB> java.lang.SecurityManager.checkPermission at
WB> java.lang.SecurityManager.checkCreateClassLoader at
WB> java.lang.ClassLoader.<init> at
WB> java.security.SecureClassLoader.<init> at
WB> java.net.URLClassLoader.<init> at
WB> org.apache.batik.script.rhino.RhinoClassLoader.<init> at
WB> org.apache.batik.script.rhino.RhinoInterpreter.<init> at
WB> org.apache.batik.script.rhino.RhinoInterpreterFactory.createInterpreter
WB> at org.apache.batik.bridge.BridgeContext.getInterpreter at
WB> org.apache.batik.BaseScriptingEnvironment.dispatchSVGLoadEvent
WB> etc.
WB> ---------------------------------------------------------------------
WB> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
WB> additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org