| Prev | Chapter 7. Kernel Documentation | Next |
|---|
+
Tcl in packages/acs-kernel
The goal of the Permissions system is to provide generic means to both @@ -48,14 +48,14 @@
The set of all defined privileges.
A relation describing the set of methods directly +
A relation describing the set of methods directly associated with each privilege.
A relation describing which privileges directly +
A relation describing which privileges directly "contain" other privileges.
A table with one (party, object, privilege) -row for every privilege directly granted on any object in +row for every privilege directly granted on any object in the system - this is a denormalization of acs_privilege_method_rules and acs_privilege_hierarchy
There are also a number of views to make it easier to ask specific @@ -78,7 +78,7 @@ a party is a member of a group (at any depth).
Relation with every (object, party, method) -tuple implied by the above trees.
In general, only acs_object_party_method_map +tuple implied by the above trees.
In general, only acs_object_party_method_map should be used for queries from other modules. The other views are intermediate steps in building that query.
The data model also includes two simple PL/SQL procedures (acs_permission.grant_permission and @@ -95,15 +95,15 @@ acs_privilege_hierarchy)
objects get access control from direct grants, or inherit permissions from their context (unless the "don't inherit" flag is set)
There are three essential areas in which all transactions in the -permissions system fall:
Modification of methods and privileges
Modification of permissions
Queries on permissions
"Modification of methods and privileges." This +permissions system fall:
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 page for manipulating these features should be limited to site-wide -administrators.
"Modification of permissions" - involves fairly +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 @@ -112,7 +112,7 @@ 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 +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 @@ -127,15 +127,15 @@ for appropriate methods.
Finally, when administering the permissions for an object, a web page needs to know all permissions directly granted on that object. This is done by querying against acs_permissions.
The API to the permissions system consists of a few well-known tables, -plus a pair of PL/SQL procedures and a pair of Tcl functions.
Tables
acs_methods, acs_privileges, and +plus a pair of PL/SQL procedures and a pair of Tcl functions.
Tables
acs_methods, acs_privileges, and acs_privilege_method_rules manage the set of permissions in the system. At installation time, a package will add to these three tables to introduce new permissions into the system.
The main table for queries is acs_object_party_method_map, which contains (object, party, method) triples for all allowed operations in the system.
Also of interest for queries is acs_permissions, which lists directly granted privileges. Neither acs_object_party_method_map (which is a view) nor acs_permissions should be updated -directly.
PL/SQL Procedures
acs_permissions.grant_permission introduces new permissions for +directly.
PL/SQL Procedures
acs_permissions.grant_permission introduces new permissions for an object. It should be given an (object, party, privilege) triple, and will always succeed. If the permission is already in the system, no change occurs. The interface for this procedure @@ -154,7 +154,7 @@ 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 +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:
ad_permission_p $object_id $object_type $method -user_id $user_id @@ -184,6 +184,4 @@
| Document Revision # | Action Taken, Notes | When? | By Whom? |
| 0.1 | Creation | 9/11/2000 | John Prevost |
| 0.2 | Edited for ACS 4 Beta release | 10/04/2000 | Kai Wu |
| Document Revision # | Action Taken, Notes | When? | By Whom? |
| 0.1 | Creation | 9/11/2000 | John Prevost |
| 0.2 | Edited for ACS 4 Beta release | 10/04/2000 | Kai Wu |