Re: Being able to set SecuritySupport on JavaScriptEngine's Context

["Victor J. Orlikowski" <vj...@dulug.duke.edu>]

On Thu, Jan 23, 2003 at 03:25:21PM -0600, Jeff Adams wrote:
> Maybe there is already a hook into this, but with the JavaScriptEngine,
> it creates Contexts with each eval within
> 
> Context.enter()
> 
> Context.exit()
> 
> blocks.
> 
> The Rhino engine has a SecuritySupport object to be optionally added 
> to Contexts
> and Apache Batik actually uses this and turns on security within 
> their copy of js.jar and makes sure Batik calls setSecuritySupport() 
> on the Context objs.
> 

Hum....I might be willing to apply a patch to the current BSF
source to do this. However, Rhino 1.5r4 deprecates the
SecuritySupport class...which makes me more likely to add support
for the new SecurityController API.

> The current JavaScriptEngine should probably have methods where one can
> setSecuritySupport() and this instance is added to each 
> Context.enter() call it makes.
> 
> One reason why I get bit by this current limitation is if you happen
> to have a copy of Batik's js.jar in your classpath and its used first,
> with its security=true setting it won't allow the JavaScriptEngine to work
> unless you have a SecuritySupport object set for the Context instances.
> 
> Yes, I know making sure only a single  js.jar file with 
> security=false should exist but to avoid tracking this down adding 
> SecuritySupport to the JavaScriptEngine is probably a better long 
> term solution?
> 

Again, submit a patch, and I will consider it.

Victor
-- 
Victor J. Orlikowski   | The Wall is Down, But the Threat Remains!
==================================================================
orlikowski@apache.org  | vjo@dulug.duke.edu | vjo@us.ibm.com

Re: Being able to set SecuritySupport on JavaScriptEngine's Context

[Igor Bukanov <ig...@icesoft.no>]

Victor J. Orlikowski wrote:
> On Thu, Jan 23, 2003 at 03:25:21PM -0600, Jeff Adams wrote:
> 
>>Maybe there is already a hook into this, but with the JavaScriptEngine,
>>it creates Contexts with each eval within
>>
>>Context.enter()
>>
>>Context.exit()
>>
>>blocks.
>>
>>The Rhino engine has a SecuritySupport object to be optionally added 
>>to Contexts
>>and Apache Batik actually uses this and turns on security within 
>>their copy of js.jar and makes sure Batik calls setSecuritySupport() 
>>on the Context objs.

The reason this was deprecated in 1.5R4 is that it never worked as 
advertised, only the portion regarding restrictions on which classes 
scripts can access worked properly and it continues to be supported in 
1.5R4.

> 
> Hum....I might be willing to apply a patch to the current BSF
> source to do this. However, Rhino 1.5r4 deprecates the
> SecuritySupport class...which makes me more likely to add support
> for the new SecurityController API.

You probably need to look at the new ClassShutter interface as well as 
it represents the working portion of the old SecuritySupport API.

>>The current JavaScriptEngine should probably have methods where one can
>>setSecuritySupport() and this instance is added to each 
>>Context.enter() call it makes.
>>
>>One reason why I get bit by this current limitation is if you happen
>>to have a copy of Batik's js.jar in your classpath and its used first,
>>with its security=true setting it won't allow the JavaScriptEngine to work
>>unless you have a SecuritySupport object set for the Context instances.
>>
>>Yes, I know making sure only a single  js.jar file with 
>>security=false should exist but to avoid tracking this down adding 
>>SecuritySupport to the JavaScriptEngine is probably a better long 
>>term solution?
>>

Rhino 1.5R4 does not use the security setting property any more and has 
explicit API to set ClassShutter or SecurityController on Context 
instances and continues to support the old setScuritySupport methods, 
but they can be called only once per Context.

Regards, Igor

Re: Being able to set SecuritySupport on JavaScriptEngine's Context

[Jeff Adams <je...@wolfram.com>]

>On Thu, Jan 23, 2003 at 03:25:21PM -0600, Jeff Adams wrote:
>>  Maybe there is already a hook into this, but with the JavaScriptEngine,
>>  it creates Contexts with each eval within
>>
>>  Context.enter()
>>
>>  Context.exit()
>>
>>  blocks.
>>
>>  The Rhino engine has a SecuritySupport object to be optionally added
>>  to Contexts
>>  and Apache Batik actually uses this and turns on security within
>>  their copy of js.jar and makes sure Batik calls setSecuritySupport()
>>  on the Context objs.
>>
>
>Hum....I might be willing to apply a patch to the current BSF
>source to do this. However, Rhino 1.5r4 deprecates the
>SecuritySupport class...which makes me more likely to add support
>for the new SecurityController API.

I agree, it is not worth dealing with the deprecated API.

Thanks
Jeff