Overview | Class | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.mozilla.javascript
Interface SecuritySupport

public interface SecuritySupport

This class describes the support needed to implement security.

Three main pieces of functionality are required to implement security for JavaScript. First, it must be possible to define classes with an associated security context. (This security context may be any object that has meaning to an embedding; for a client-side JavaScript embedding this would typically be an origin URL and/or a digital certificate.) Next it must be possible to get the current class context so that the implementation can determine securely which class is requesting a privileged action. And finally, it must be possible to map a class back into a security context so that additional classes may be defined with that security context.

These three pieces of functionality are encapsulated in the SecuritySupport class.

Additionally, an embedding may provide filtering on the Java classes that are visible to scripts through the `visibleToScripts` method.

Since:
  1.4 Release 2
Author:
  Norris Boyd
See Also:
  `Context`, `ClassLoader`

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.

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.

  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.

### 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.

  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.

  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

Overview | Class | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD