Re: applet security rhino interpreter

[Thomas DeWeese]

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" <[EMAIL PROTECTED]>
 

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]