xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: applet security rhino interpreter
Date Wed, 11 Jun 2003 12:03:45 GMT
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
>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.

>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" <thomas.deweese@kodak.com>
>To: "Batik Users" <batik-users@xml.apache.org>
>Sent: Tuesday, June 10, 2003 5:55 PM
>Subject: RE: applet security rhino interpreter
>>>>>>>"S" == Stephen  <stephen.turner@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?
>>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

View raw message