org.concord.util.script
Class Script.ScriptSecuritySupport

java.lang.Object
  |
  +--org.concord.util.script.Script.ScriptSecuritySupport

All Implemented Interfaces:

org.mozilla.javascript.SecuritySupport

Enclosing class:

Script

public class Script.ScriptSecuritySupport

extends java.lang.Object

implements org.mozilla.javascript.SecuritySupport

Constructor Summary

Script.ScriptSecuritySupport()

Method Summary

java.lang.Class	defineClass(java.lang.String name, byte[] data, java.lang.Object securityDomain) Define and load a Java class.
java.lang.Class[]	getClassContext() Get the current class Context.
java.lang.Object	getSecurityDomain(java.lang.Class cl) Return the security context associated with the given class.
boolean	visibleToScripts(java.lang.String fullClassName) Return true iff the Java class with the given name should be exposed to scripts.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

Script.ScriptSecuritySupport

public Script.ScriptSecuritySupport()

Method Detail

defineClass

public java.lang.Class defineClass(java.lang.String name,
                                   byte[] data,
                                   java.lang.Object securityDomain)

Define and load a Java class.

In embeddings that care about security, the securityDomain must be associated with the defined class such that a call to getSecurityDomain with that class will return this security context.

Specified by:

defineClass in interface org.mozilla.javascript.SecuritySupport

Parameters:

name - the name of the class

data - the bytecode of the class

securityDomain - some object specifying the security context of the code that is defining this class. Embeddings that don't care about security may allow null here. This value propagated from the values passed into methods of Context that evaluate scripts.

getClassContext

public java.lang.Class[] getClassContext()

Get the current class Context.

This functionality is supplied by SecurityManager.getClassContext, but only one SecurityManager may be instantiated in a single JVM at any one time. So implementations that care about security must provide access to this functionality through this interface.

Note that the 0th entry of the returned array should be the class of the caller of this method. So if this method is implemented by calling SecurityManager.getClassContext, this method must allocate a new, shorter array to return.

Specified by:

getClassContext in interface org.mozilla.javascript.SecuritySupport

getSecurityDomain

public java.lang.Object getSecurityDomain(java.lang.Class cl)

Return the security context associated with the given class.

If cl is a class defined through a call to SecuritySupport.defineClass, then return the security context from that call. Otherwise return null.

Specified by:

getSecurityDomain in interface org.mozilla.javascript.SecuritySupport

Parameters:

cl - a class potentially defined by defineClass

Returns:

a security context object previously passed to defineClass

visibleToScripts

public boolean visibleToScripts(java.lang.String fullClassName)

Return true iff the Java class with the given name should be exposed to scripts.

An embedding may filter which Java classes are exposed through LiveConnect to JavaScript scripts.

Due to the fact that there is no package reflection in Java, this method will also be called with package names. There is no way for Rhino to tell if "Packages.a.b" is a package name or a class that doesn't exist. What Rhino does is attempt to load each segment of "Packages.a.b.c": It first attempts to load class "a", then attempts to load class "a.b", then finally attempts to load class "a.b.c". On a Rhino installation without any SecuritySupport set, and without any of the above classes, the expression "Packages.a.b.c" will result in a [JavaPackage a.b.c] and not an error.

With SecuritySupport supplied, Rhino will first call visibleToScripts before attempting to look up the class name. If visibleToScripts returns false, the class name lookup is not performed and subsequent Rhino execution assumes the class is not present. So for "java.lang.System.out.println" the lookup of "java.lang.System" is skipped and thus Rhino assumes that "java.lang.System" doesn't exist. So then for "java.lang.System.out", Rhino attempts to load the class "java.lang.System.out" because it assumes that "java.lang.System" is a package name.

Specified by:

visibleToScripts in interface org.mozilla.javascript.SecuritySupport

Parameters:

fullClassName - the full name of the class (including the package name, with '.' as a delimiter). For example the standard string class is "java.lang.String"

Returns:

whether or not to reveal this class to scripts