SecurityManager

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(anExecutableObject, [policy])

Add an ExecutableObject to the current security context. Optionally, add a new SecurityPolicy as well.

removeContext(anExecutableObject, [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?