The OpenACS 5.9.0 Permissions system allows developers and
administrators to set access control policies at the object level,
that is, any application or system object represented by a row in
the acs_objects table can be
-access-controlled via a PL/SQL or Tcl interface. The permissions
+access-controlled via a PL/SQL or Tcl interface. The permission
system manages a data model that then allows scripts to check
permissions using another API call.
Although object level permissions seems appropriate, no developer or administrator wants to explicitly set access control rights for @@ -26,7 +33,7 @@ applications to group objects together into larger security domains.
The rest of this document discusses each of these parts, and how -they fit together with the permissions system.
+they fit together with the permission system.OpenACS 5.9.0 has an abstraction called a party. Parties have a recursive @@ -68,8 +75,8 @@ Design for more details.
NOTE: Much more detailed information about the permissions -system and how to use it is available in the OpenACS Permissions +Permissions
NOTE: Much more detailed information about the permission system +and how to use it is available in the OpenACS Permissions Tediously Explained document.
The permissions data model is a mapping between privileges, parties and objects. Parties and objects have already been discussed. Now we focus on privileges.
In OpenACS, a privilege describes the right to perform some @@ -106,7 +113,7 @@ explicitly require admin privileges. No substitutions.
To give a user permission to perform a particular operation on a
particular object you call acs_permission.grant_permission like
this:
-# sql code
+# SQL code
acs_permission.grant_permission (
object_id => some_object_id,
grantee_id => some_party_id,
@@ -116,7 +123,7 @@
Using just these mechanisms is enough for developers and administrators to effectively define access control for every object in a system.
Explicitly defining permissions to every object individually -would become very tedious. OpenACS provides a object contexts as a +would become very tedious. OpenACS provides object contexts as a means for controlling permissions of a large group of objects at the same time.
The Context hierarchy allows you to define organize default permissions in a hierarchical fashion.
A PL/SQL or Tcl API is then used to check permissions in -application pages.
($Id: permissions.xml,v 1.18 2017/08/07 -23:47:54 gustafn Exp $)
+application pages.