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 Stephen <st...@ilc.com> on 2003/06/10 18:38:46 UTC
applet security rhino interpreter
I'm having security problems with the applet (act surprised AGAIN!)
allowing the RhinoInterpreter to create a class loader. Do I have to use
the rhinoClassLoader that is created in the constructor of
RhinoInterpreter? Can I use the applet class loader instead? I really
dread having to require everyone who runs the applet to update their
security policy for it to run.
BTW: I used Crimson instead of xerces for the applet and it worked just
fine.
Thanks,
Stephen.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: applet security rhino interpreter
Posted by Thomas DeWeese <Th...@Kodak.com>.
William Billingsley wrote:
>That sounds absolutely marvellous! Thankyou so much. Where can I get the
>updated code and/or jars from?
>
>
I will probably commit the changes to CVS tonight. It will also
include the move to the
tri-stated JSVGCanvas (STATIC, INTERACTIVE, DYNAMIC) - more on that
later though.
>William.
>
>
>From: "Thomas DeWeese" <Th...@Kodak.com>
>
>
>>Hi William,
>>
>> I just took a look at this and I made the evaluation of the
>>contentScriptType attribute lazy.
>>So unless you set one of the 'script' attributes ('onload',
>>'onmouseover', yadah, yadah, yadah)
>>it doesn't matter what contentScriptType is set to. This also
>>simplified the code somewhat, allowed
>>me to only issue the 'unknown language' error once per language, and
>>probably improved
>>performance in several cases.
>>
>> This should mean that you can just remove the script/rhino package
>>from your applet (along
>>with js.jar) and not have any problems (as long as you don't load
>>documents that want to use scripting of course). Does this seem like a
>>suitable solution to your problems?
>>
>>William Billingsley wrote:
>>
>>
>>
>>>Thought I'd pitch back in since my message was linked...
>>>
>>>I haven't tried removing the Rhino classes (though it might work) because
>>>there seems to be another issue that is really the crux of the problem
>>>
>>>
>[this
>
>
>>>is just a symptom]. Batik only tries to load the Rhino interpreter at
>>>
>>>
>all
>
>
>>>because of the contentScriptType="text/ecmascript" attribute on the SVG.
>>>This is a default attribute in Batik, and cannot be removed, only changed
>>>
>>>
>(I
>
>
>>>understand in SVG 1.0 this is a required element; ironically it isn't
>>>required in the drafts for SVG 1.1).
>>>Consequently, shortly after Rhino fails to load, an "unknown language:
>>>text/ecmascript" error occurs.
>>>
>>>There seem to be only two solutions:
>>>1. Make the document Static to the canvas -- but this also prevents the
>>>
>>>
>DOM
>
>
>>>update listener from loading, which is rather useless if you actually
>>>
>>>
>want
>
>
>>>to make any alterations to the SVG document from within your applet (as I
>>>do).
>>>2. Change the contentScriptType.
>>>
>>>The seemingly obvious solution would be to change the contentScriptType
>>>
>>>
>to
>
>
>>>Java (I forget the tag), since you probably will be adding DOM listeners
>>>
>>>
>>>from your applet. This has the snag that Batik then expects the Java
>>
>>
>>>"script" attached to the document to be another set of classes that it
>>>
>>>
>will
>
>
>>>dynamically instansiate, and not the pre-existing and
>>>
>>>
>already-instansiated
>
>
>>>classes of your applet. [which holes that idea unless you want to
>>>
>>>
>majorly
>
>
>>>re-engineer your applet in a very maintenance-hard way].
>>>
>>>
>>>The temporary solution I am looking at is changing the contentScriptType
>>>
>>>
>to
>
>
>>>a constant (something like ThrowawayThisException), and subclassing the
>>>JSVGCanvas user agent to specifically suppress the "unknown language:
>>>ThrowawayThisException" exception -- the exception will still happen but
>>>
>>>
>the
>
>
>>>user never will never see it and it won't stop anything from running.
>>>
>>>
>>>
>> I'm not sure this will work with the current architecture as I think
>>you may get errors before the
>>DOM events are generated (the new system should always send the event to
>>the DOM even if the
>>script can be fired).
>>
>>
>>
>>>More ideally, it would be nice if the "Dynamic Support" setting in the
>>>JSVGCanvas could be split into two separate settings for DOM Update
>>>Listening support and Scripting Support.
>>>
>>>
>>>
>> This could be done as scripting is implemented as simply attaching
>>additional listeners to the DOM,
>>but the lazy approach I think solves this problem and avoids introducing
>>another 'dynamic' state.
>>
>>
>>
>
>
>---------------------------------------------------------------------
>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 security rhino interpreter
Posted by William Billingsley <wh...@cam.ac.uk>.
That sounds absolutely marvellous! Thankyou so much. Where can I get the
updated code and/or jars from?
William.
From: "Thomas DeWeese" <Th...@Kodak.com>
> Hi William,
>
> I just took a look at this and I made the evaluation of the
> contentScriptType attribute lazy.
> So unless you set one of the 'script' attributes ('onload',
> 'onmouseover', yadah, yadah, yadah)
> it doesn't matter what contentScriptType is set to. This also
> simplified the code somewhat, allowed
> me to only issue the 'unknown language' error once per language, and
> probably improved
> performance in several cases.
>
> This should mean that you can just remove the script/rhino package
> from your applet (along
> with js.jar) and not have any problems (as long as you don't load
> documents that want to use scripting of course). Does this seem like a
> suitable solution to your problems?
>
> William Billingsley wrote:
>
> >Thought I'd pitch back in since my message was linked...
> >
> >I haven't tried removing the Rhino classes (though it might work) because
> >there seems to be another issue that is really the crux of the problem
[this
> >is just a symptom]. Batik only tries to load the Rhino interpreter at
all
> >because of the contentScriptType="text/ecmascript" attribute on the SVG.
> >This is a default attribute in Batik, and cannot be removed, only changed
(I
> >understand in SVG 1.0 this is a required element; ironically it isn't
> >required in the drafts for SVG 1.1).
> >Consequently, shortly after Rhino fails to load, an "unknown language:
> >text/ecmascript" error occurs.
> >
> >There seem to be only two solutions:
> >1. Make the document Static to the canvas -- but this also prevents the
DOM
> >update listener from loading, which is rather useless if you actually
want
> >to make any alterations to the SVG document from within your applet (as I
> >do).
> >2. Change the contentScriptType.
> >
> >The seemingly obvious solution would be to change the contentScriptType
to
> >Java (I forget the tag), since you probably will be adding DOM listeners
> >from your applet. This has the snag that Batik then expects the Java
> >"script" attached to the document to be another set of classes that it
will
> >dynamically instansiate, and not the pre-existing and
already-instansiated
> >classes of your applet. [which holes that idea unless you want to
majorly
> >re-engineer your applet in a very maintenance-hard way].
> >
> >
> >The temporary solution I am looking at is changing the contentScriptType
to
> >a constant (something like ThrowawayThisException), and subclassing the
> >JSVGCanvas user agent to specifically suppress the "unknown language:
> >ThrowawayThisException" exception -- the exception will still happen but
the
> >user never will never see it and it won't stop anything from running.
> >
> I'm not sure this will work with the current architecture as I think
> you may get errors before the
> DOM events are generated (the new system should always send the event to
> the DOM even if the
> script can be fired).
>
> >More ideally, it would be nice if the "Dynamic Support" setting in the
> >JSVGCanvas could be split into two separate settings for DOM Update
> >Listening support and Scripting Support.
> >
> This could be done as scripting is implemented as simply attaching
> additional listeners to the DOM,
> but the lazy approach I think solves this problem and avoids introducing
> another 'dynamic' state.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: applet security rhino interpreter
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi William,
I just took a look at this and I made the evaluation of the
contentScriptType attribute lazy.
So unless you set one of the 'script' attributes ('onload',
'onmouseover', yadah, yadah, yadah)
it doesn't matter what contentScriptType is set to. This also
simplified the code somewhat, allowed
me to only issue the 'unknown language' error once per language, and
probably improved
performance in several cases.
This should mean that you can just remove the script/rhino package
from your applet (along
with js.jar) and not have any problems (as long as you don't load
documents that want to use scripting of course). Does this seem like a
suitable solution to your problems?
William Billingsley wrote:
>Thought I'd pitch back in since my message was linked...
>
>I haven't tried removing the Rhino classes (though it might work) because
>there seems to be another issue that is really the crux of the problem [this
>is just a symptom]. Batik only tries to load the Rhino interpreter at all
>because of the contentScriptType="text/ecmascript" attribute on the SVG.
>This is a default attribute in Batik, and cannot be removed, only changed (I
>understand in SVG 1.0 this is a required element; ironically it isn't
>required in the drafts for SVG 1.1).
>Consequently, shortly after Rhino fails to load, an "unknown language:
>text/ecmascript" error occurs.
>
>There seem to be only two solutions:
>1. Make the document Static to the canvas -- but this also prevents the DOM
>update listener from loading, which is rather useless if you actually want
>to make any alterations to the SVG document from within your applet (as I
>do).
>2. Change the contentScriptType.
>
>The seemingly obvious solution would be to change the contentScriptType to
>Java (I forget the tag), since you probably will be adding DOM listeners
>from your applet. This has the snag that Batik then expects the Java
>"script" attached to the document to be another set of classes that it will
>dynamically instansiate, and not the pre-existing and already-instansiated
>classes of your applet. [which holes that idea unless you want to majorly
>re-engineer your applet in a very maintenance-hard way].
>
>
>The temporary solution I am looking at is changing the contentScriptType to
>a constant (something like ThrowawayThisException), and subclassing the
>JSVGCanvas user agent to specifically suppress the "unknown language:
>ThrowawayThisException" exception -- the exception will still happen but the
>user never will never see it and it won't stop anything from running.
>
I'm not sure this will work with the current architecture as I think
you may get errors before the
DOM events are generated (the new system should always send the event to
the DOM even if the
script can be fired).
>More ideally, it would be nice if the "Dynamic Support" setting in the
>JSVGCanvas could be split into two separate settings for DOM Update
>Listening support and Scripting Support.
>
This could be done as scripting is implemented as simply attaching
additional listeners to the DOM,
but the lazy approach I think solves this problem and avoids introducing
another 'dynamic' state.
>cheers,
>Will.
>
>PS. My experience with Batik is limited to about a month, so anyone more
>knowledgeable feel free to correct me.
>
>
>----- Original Message -----
>From: "Thomas E Deweese" <th...@kodak.com>
>To: "Batik Users" <ba...@xml.apache.org>
>Sent: Tuesday, June 10, 2003 5:55 PM
>Subject: RE: applet security rhino interpreter
>
>
>
>
>>>>>>>"S" == Stephen <st...@ilc.com> writes:
>>>>>>>
>>>>>>>
>>S> I'm having security problems with the applet (act surprised AGAIN!)
>>S> allowing the RhinoInterpreter to create a class loader. Do I have
>>S> to use the rhinoClassLoader that is created in the constructor of
>>S> RhinoInterpreter? Can I use the applet class loader instead? I
>>S> really dread having to require everyone who runs the applet to
>>S> update their security policy for it to run.
>>
>> Do you need script support? If you not might be able to leave the
>>rhino package out of your Applet. If you need JavaScript support then
>>things get tricky. See one of the cool things about Rhino is that it
>>compiles your JavaScript in ByteCode then loads it and runs it - I
>>don't think this can be done with the Applet Class Loader.
>>
>> A week or two ago there was a thread on just this, someone
>>mentioned that they were able to hack Rhino by simply removing the
>>optimization classes - perhaps the two of you can sort this out and
>>post results?
>>
>>http://koala.ilog.fr/batik/mlists/batik-users/archives/msg03506.html
>>
>>S> BTW: I used Crimson instead of xerces for the applet and it worked
>>S> just fine.
>>
>> Glad to hear it.
>>
>>
>>---------------------------------------------------------------------
>>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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: applet security rhino interpreter
Posted by William Billingsley <wh...@cam.ac.uk>.
Thought I'd pitch back in since my message was linked...
I haven't tried removing the Rhino classes (though it might work) because
there seems to be another issue that is really the crux of the problem [this
is just a symptom]. Batik only tries to load the Rhino interpreter at all
because of the contentScriptType="text/ecmascript" attribute on the SVG.
This is a default attribute in Batik, and cannot be removed, only changed (I
understand in SVG 1.0 this is a required element; ironically it isn't
required in the drafts for SVG 1.1).
Consequently, shortly after Rhino fails to load, an "unknown language:
text/ecmascript" error occurs.
There seem to be only two solutions:
1. Make the document Static to the canvas -- but this also prevents the DOM
update listener from loading, which is rather useless if you actually want
to make any alterations to the SVG document from within your applet (as I
do).
2. Change the contentScriptType.
The seemingly obvious solution would be to change the contentScriptType to
Java (I forget the tag), since you probably will be adding DOM listeners
from your applet. This has the snag that Batik then expects the Java
"script" attached to the document to be another set of classes that it will
dynamically instansiate, and not the pre-existing and already-instansiated
classes of your applet. [which holes that idea unless you want to majorly
re-engineer your applet in a very maintenance-hard way].
The temporary solution I am looking at is changing the contentScriptType to
a constant (something like ThrowawayThisException), and subclassing the
JSVGCanvas user agent to specifically suppress the "unknown language:
ThrowawayThisException" exception -- the exception will still happen but the
user never will never see it and it won't stop anything from running.
More ideally, it would be nice if the "Dynamic Support" setting in the
JSVGCanvas could be split into two separate settings for DOM Update
Listening support and Scripting Support.
cheers,
Will.
PS. My experience with Batik is limited to about a month, so anyone more
knowledgeable feel free to correct me.
----- Original Message -----
From: "Thomas E Deweese" <th...@kodak.com>
To: "Batik Users" <ba...@xml.apache.org>
Sent: Tuesday, June 10, 2003 5:55 PM
Subject: RE: applet security rhino interpreter
> >>>>> "S" == Stephen <st...@ilc.com> writes:
>
> S> I'm having security problems with the applet (act surprised AGAIN!)
> S> allowing the RhinoInterpreter to create a class loader. Do I have
> S> to use the rhinoClassLoader that is created in the constructor of
> S> RhinoInterpreter? Can I use the applet class loader instead? I
> S> really dread having to require everyone who runs the applet to
> S> update their security policy for it to run.
>
> Do you need script support? If you not might be able to leave the
> rhino package out of your Applet. If you need JavaScript support then
> things get tricky. See one of the cool things about Rhino is that it
> compiles your JavaScript in ByteCode then loads it and runs it - I
> don't think this can be done with the Applet Class Loader.
>
> A week or two ago there was a thread on just this, someone
> mentioned that they were able to hack Rhino by simply removing the
> optimization classes - perhaps the two of you can sort this out and
> post results?
>
> http://koala.ilog.fr/batik/mlists/batik-users/archives/msg03506.html
>
> S> BTW: I used Crimson instead of xerces for the applet and it worked
> S> just fine.
>
> Glad to hear it.
>
>
> ---------------------------------------------------------------------
> 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 security rhino interpreter
Posted by Stephen <st...@ilc.com>.
Sorry for the delay but yes I do in fact need script support. I wrote an
applet/server implementation where the server tells the applet svg
viewer through socket interface what values to change and so forth by
sending scripting commands. It actually works really well. I've been
able to setup the policy to get around it for now but it still bugs me.
I'll have to look a little closer at the RhinoClassLoader to find ways
to get around this.
Thanks,
Stephen.
-----Original Message-----
From: Thomas E Deweese [mailto:thomas.deweese@kodak.com]
Sent: Tuesday, June 10, 2003 12:55 PM
To: Batik Users
Subject: RE: applet security rhino interpreter
>>>>> "S" == Stephen <st...@ilc.com> writes:
S> I'm having security problems with the applet (act surprised AGAIN!)
S> allowing the RhinoInterpreter to create a class loader. Do I have
S> to use the rhinoClassLoader that is created in the constructor of
S> RhinoInterpreter? Can I use the applet class loader instead? I
S> really dread having to require everyone who runs the applet to
S> update their security policy for it to run.
Do you need script support? If you not might be able to leave the
rhino package out of your Applet. If you need JavaScript support then
things get tricky. See one of the cool things about Rhino is that it
compiles your JavaScript in ByteCode then loads it and runs it - I
don't think this can be done with the Applet Class Loader.
A week or two ago there was a thread on just this, someone
mentioned that they were able to hack Rhino by simply removing the
optimization classes - perhaps the two of you can sort this out and
post results?
http://koala.ilog.fr/batik/mlists/batik-users/archives/msg03506.html
S> BTW: I used Crimson instead of xerces for the applet and it worked
S> just fine.
Glad to hear it.
---------------------------------------------------------------------
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 security rhino interpreter
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "S" == Stephen <st...@ilc.com> writes:
S> I'm having security problems with the applet (act surprised AGAIN!)
S> allowing the RhinoInterpreter to create a class loader. Do I have
S> to use the rhinoClassLoader that is created in the constructor of
S> RhinoInterpreter? Can I use the applet class loader instead? I
S> really dread having to require everyone who runs the applet to
S> update their security policy for it to run.
Do you need script support? If you not might be able to leave the
rhino package out of your Applet. If you need JavaScript support then
things get tricky. See one of the cool things about Rhino is that it
compiles your JavaScript in ByteCode then loads it and runs it - I
don't think this can be done with the Applet Class Loader.
A week or two ago there was a thread on just this, someone
mentioned that they were able to hack Rhino by simply removing the
optimization classes - perhaps the two of you can sort this out and
post results?
http://koala.ilog.fr/batik/mlists/batik-users/archives/msg03506.html
S> BTW: I used Crimson instead of xerces for the applet and it worked
S> just fine.
Glad to hear it.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org