History for SecurityManager
??changed:
-
A security manager provides methods for checking access and managing
executable context and policies:
validate(![accessed, container, name, value]) --
Validate access.
Arguments:
accessed -- the object that was being accessed
container -- the object the value was found in
name -- The name used to access the value
value -- The value retrieved though the access.
The arguments may be provided as keyword arguments. Some of these
arguments may be ommitted, however, the policy may reject access
in some cases when arguments are ommitted. It is best to provide
all the values possible.
checkPermission(permission, object) --
Check whether the security context allows the given permission on
the given object.
Arguments:
permission -- A permission name
object -- The object being accessed according to the permission
addContext(an[ExecutableObject], ![policy]) --
Add an ExecutableObject to the current security
context. Optionally, add a new SecurityPolicy as well.
removeContext(an[ExecutableObject], ![policy]) -- Remove an
ExecutableObject, and optionally, a SecurityPolicy, from the
current security context.
Brian -- does this mean that only an ExecutableObject
can be added as extra context?
Jim -- Good point. This should probably call for
some other as yet undefined interface. As mentioned
in the ExecutableObject page, the reqired interface
will, to some degree, be dictated by the policy.
Are there other types
of added context (the caller maybe? referrer?).
Jim -- The caller would be in the context stack if
it registers itself.
The referer would be in the REQUEST, which is in
the context.
A meta note - we should add the expected return
values (or exception throwing behavior) to our interface
descriptions.
Jim -- Yup, and also the security information. For
example, can the thing be called from DTML? using
a URL? What permission?