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?