For programmers, the Permissions API provides a means to work -with access control in a consistent manner. If a programmer's +operation to be individually granted or revoked from a user. +It's expected that the Permissions system will be seeing a lot +of use - almost every page will make at least one permissions API +call, and some will make several.
For programmers, the Permissions API provides a means to work +with access control in a consistent manner. If a programmer's OpenACS package defines new methods for itself, the Permissions API must provide simple calls to determine whether the current user is authorized to perform the given method. In addition, using the @@ -52,9 +52,9 @@ registered user to access its pages read-only, but only allow members of a certain group to make changes. The way this group was determined also varied greatly between modules. Some modules used -"roles", while others did not. Other modules did all access control -based simply on coded rules regarding who can act on a given -database row based on the information in that row.
Problems resulting from this piecemeal approach to permissions +"roles", while others did not. Other modules did all +access control based simply on coded rules regarding who can act on +a given database row based on the information in that row.
Problems resulting from this piecemeal approach to permissions and access control were many, the two major ones being inconsistency, and repeated/redundant code. Thus the drive in OpenACS 4 to provide a unified, consistent permissions system that @@ -90,10 +90,10 @@
There are also a number of views to make it easier to ask specific questions about permissions. For example, a number of the -above tables describe "direct" or explicit permissions. Inheritance -and default values can, however, introduce permissions which are -not directly specified. (For example, read access on a forum allows -read access on all the messages in the forum.)
The following views provide flattened versions of inherited +above tables describe "direct" or explicit permissions. +Inheritance and default values can, however, introduce permissions +which are not directly specified. (For example, read access on a +forum allows read access on all the messages in the forum.)
The following views provide flattened versions of inherited information:
acs_privilege_method_mapMap of privileges to the methods they contain either directly or because of another privilege which is included (at any depth).
acs_object_grantee_priv_mapRelation on (object, @@ -124,8 +124,8 @@ indirectly a member of
privileges get associated with the methods of any other
privileges they have taken methods from (at any level) (see
acs_privilege_hierarchy)
objects get access control from direct grants, or inherit -permissions from their context (unless the "don't inherit" flag is -set)
Modification of methods and privileges
Modification of permissions
Queries on permissions
"Modification of methods and -privileges." This refers to actions that happen -mainly at package installation time - a package will create a -number of methods for its own use, then associate them with the -system's standard privileges, or new privileges which the package -has created. The association step might also happen later, if the -site-wide administrator chooses to change permissions policy.
These steps involve directly manipulating the acs_methods, acs_privileges, and acs_privilege_method_rules tables. A web
+privileges." This refers to actions that
+happen mainly at package installation time - a package will create
+a number of methods for its own use, then associate them with the
+system's standard privileges, or new privileges which the
+package has created. The association step might also happen later,
+if the site-wide administrator chooses to change permissions
+policy.
These steps involve directly manipulating the acs_methods, acs_privileges, and acs_privilege_method_rules tables. A web
page for manipulating these features should be limited to site-wide
administrators.
"Modification of
-permissions" - involves fairly common operations.
-Users are typically able to administer permissions for objects they
-themselves create. The two basic operations here are "grant" and
-"revoke". Granting permissions is done via acs_permissions.grant_permission, and
+permissions" - involves fairly common
+operations. Users are typically able to administer permissions for
+objects they themselves create. The two basic operations here are
+"grant" and "revoke". Granting permissions is
+done via acs_permissions.grant_permission, and
revocation via acs_permissions.revoke_permission. These
directly manipulate the acs_permissions table.
Web pages for making these changes are available to all users,
so they should not be in an admin area. In order to grant and
revoke permissions on an object, the user must have the
administer_privileges method
permission on that object.
"Queries on
-permissions" - by far the most common operation is
-querying the permissions database. Several kinds of questions are
-commonly asked: First, and most commonly, "Can this party perform
-this method on this object?" Two Tcl functions are provided to
-answer this - one which returns a boolean, the other of which
-results in an error page. These tcl functions directly access the
-acs_object_party_method_map.
The second most commonly asked question occurs when a list of
+permissions" - by far the most common
+operation is querying the permissions database. Several kinds of
+questions are commonly asked: First, and most commonly, "Can
+this party perform this method on this object?" Two Tcl
+functions are provided to answer this - one which returns a
+boolean, the other of which results in an error page. These tcl
+functions directly access the acs_object_party_method_map.
The second most commonly asked question occurs when a list of
objects is being displayed, often in order to provide appropriate
-UI functionality: "For this party, what methods are available on
-these objects?" Here, the SQL query needs to filter based on
-whether the party/user can perform some operation on the object.
+UI functionality: "For this party, what methods are available
+on these objects?" Here, the SQL query needs to filter based
+on whether the party/user can perform some operation on the object.
This is done via a join or sub-select against acs_object_party_method_map, or by calling
the Tcl functions for appropriate methods.
Finally, when administering the permissions for an object, a web page needs to know all permissions directly granted on that object. @@ -204,9 +206,9 @@ privilege acs_permissions.privilege%TYPE );
These procedures are defined in permissions-create.sql
-
Tcl Procedures
Two tcl procedures provide a simple call for the query, "Can -this user perform this method on this object?" One returns true or -false, the other presents an error page.
To receive a true or false value, Tcl code should call:
+Tcl Procedures
Two tcl procedures provide a simple call for the query, +"Can this user perform this method on this object?" One +returns true or false, the other presents an error page.
To receive a true or false value, Tcl code should call:
permission::permission_p -object_id $object_id -party_id $user_id -privilege $methodIf the
user_idargument is left out, then the currently logged in user is checked. To create @@ -226,10 +228,10 @@ providing a list of all possible permissions and a list of all parties in the system. (For large sites, some future search mechanism will be necessary.) After choosing privileges to grant, -the user is returned to the "edit privileges for one object" -screen.If it makes sense, the system will also display a checkbox which +the user is returned to the "edit privileges for one +object" screen.
If it makes sense, the system will also display a checkbox which the user may select to toggle whether permissions are inherited -from the object's context.
There are a number of potential future enhancements for the +from the object's context.
There are a number of potential future enhancements for the permissions UI, outlined below.
There should be a page displaying a list of all objects for which the current user is allowed to administer privileges.
Users should be able to view the permissions on any object, or -perhaps on objects which they have the "read_permissions" method. -This would allow them to see what grants are affecting their -objects through inheritance.