A security manager provides methods for checking access and managing executable context and policies:
- validate([accessed, container, name, value])
- Validate access.
- the object that was being accessed
- the object the value was found in
- The name used to access the 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.
- A permission name
- 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.
- does this mean that only an ExecutableObject
can be added as extra context?
- 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?).
- 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.
- Yup, and also the security information. For example, can the thing be called from DTML? using a URL? What permission?