| A
- object_id=10
+ Table�11.2.� | A
+ object_id=10
| | B
- object_id=20
+ object_id=20
| C
- object_id=30
+ object_id=30
| | D
- object_id=40
+ object_id=40
| E
- object_id=50
+ object_id=50
| F
- object_id=60
+ object_id=60
|
- This can be represented in the
+ This can be represented in the
acs_objects table
by the following entries:
- Table�11.3.� | object_id | context_id |
|---|
| 20 | 10 | | 30 | 10 | | 40 | 20 | | 50 | 20 | | 60 | 30 |
+ Table�11.3.� | object_id | context_id |
|---|
| 20 | 10 | | 30 | 10 | | 40 | 20 | | 50 | 20 | | 60 | 30 |
The first entry tells us that object 20 is the descendant of object 10, and
the third entry shows that object 40 is the descendant of object 20. By
running a CONNECT BY query,
we can compute that object 40 is the second-generation descendant of object 10.
With this in mind, if we want to record the fact that user Joe has the read privilege on objects
A, ..., F, we only need to record one entry in the
- acs_permissions table.
- Table�11.4.� | object | grantee | privilege |
|---|
| A | Joe | read |
+ acs_permissions table.
+ Table�11.4.� | object | grantee | privilege |
|---|
| A | Joe | read |
The fact that Joe can also read B, C,
..., and F can be derived by ascertaining that these objects
are children of A by traversing the context hierarchy.
As it turns out, hierarchical queries are expensive. As
Rafael Schloming put it so aptly, Oracle can't deal with hierarchies for shit.
One way to solve this problem is to cache a flattened view of the context tree like so:
- Table�11.5.� | object | ancestor | n_generations |
|---|
| A | A | 0 | | B | B | 0 | | B | A | 1 | | C | C | 0 | | C | A | 1 | | D | D | 0 | | D | B | 1 | | D | A | 2 | | E | E | 0 | | E | B | 1 | | E | A | 2 | | F | F | 0 | | F | C | 1 | | F | A | 2 |
+ Table�11.5.� | object | ancestor | n_generations |
|---|
| A | A | 0 | | B | B | 0 | | B | A | 1 | | C | C | 0 | | C | A | 1 | | D | D | 0 | | D | B | 1 | | D | A | 2 | | E | E | 0 | | E | B | 1 | | E | A | 2 | | F | F | 0 | | F | C | 1 | | F | A | 2 |
Note that the number of entries in the flattened view grows exponentially with
respect to the depth of the context tree. For instance, if you have a fully
populated binary tree with a depth of n, then the number of entries
@@ -143,7 +142,7 @@
Despite its potentially great storage costs, maintaining a
flattened representation of the context tree is exactly what OpenACS 4.x
does. The flattened context tree is stored in the
- acs_object_context_index table.
+ acs_object_context_index table.
create table acs_object_context_index (
object_id
@@ -154,7 +153,7 @@
constraint acs_obj_context_idx_anc_id_fk references acs_objects(object_id),
n_generations integer
not null
- constraint acs_obj_context_idx_n_gen_ck check (n_generations >= 0),
+ constraint acs_obj_context_idx_n_gen_ck check (n_generations >= 0),
constraint acs_object_context_index_pk
primary key (object_id, ancestor_id)
) organization index;
@@ -168,8 +167,8 @@
has, and exponentially
with respect to the depth of the context tree.
- The acs_object_context_index is kept in sync with the
- acs_objects
+ The acs_object_context_index is kept in sync with the
+ acs_objects
table by triggers like this:
create or replace trigger acs_objects_context_id_in_tr
@@ -199,40 +198,40 @@
end if;
end;
- One final note about
+ One final note about
acs_objects. By setting
- an object's security_inherit_p column to 'f', you can stop permissions
+ an object's security_inherit_p column to 'f', you can stop permissions
from cascading down the context tree. In the following example, Joe does not have
the read permissions on C and F.
- Table�11.6.�
+
Table�11.6.�
A
-object_id=10
+object_id=10
readable�by�Joe
������
|
B
-object_id=20
+object_id=20
readable�by�Joe
��������������
|
C
-object_id=30
+object_id=30
security_inherit_p�=�'f'
not�readable�by�Joe
������
|
D
-object_id=40
+object_id=40
������
|
E
-object_id=50
+object_id=50
������
|
F
-object_id=60
+object_id=60
security_inherit_p�=�'f'
not�readable�by�Joe
- ������
|
|
Privileges are also organized hierarchically. In addition to the five main system privileges
defined in the ACS Kernel data model, application developers may define their own. For instance,
the Bboard package defines the following privileges:
- Table�11.7.� | privilege |
|---|
| create_category | | create_forum | | create_message | | delete_category | | delete_forum | | delete_message | | moderate_forum | | read_category | | read_forum | | read_message | | write_category | | write_forum | | write_message |
+ Table�11.7.� | privilege |
|---|
| create_category | | create_forum | | create_message | | delete_category | | delete_forum | | delete_message | | moderate_forum | | read_category | | read_forum | | read_message | | write_category | | write_forum | | write_message |
By defining parent-child relationship between privileges, the OpenACS data model
makes it easier for developers to manage permissions. Instead of granting
a user explicit read, write, delete,
@@ -241,9 +240,9 @@
privilege to which the first four privileges are tied. To give
a more detailed example, the Bboard privileges are structured
as follows.
- Table�11.8.� | admin | | create | delete | read | write | moderate forum | | create category | create forum | create message | delete category | delete forum | delete message | read category | read forum | read message | write category | write forum | write message |
+ Table�11.8.� | admin | | create | delete | read | write | moderate forum | | create category | create forum | create message | delete category | delete forum | delete message | read category | read forum | read message | write category | write forum | write message |
The parent-child relationship between privileges is represented in
- the acs_privilege_hierarchy table:
+ the acs_privilege_hierarchy table:
create table acs_privilege_hierarchy (
privilege
@@ -284,10 +283,10 @@
reasonably small, there is no pressing need to cache the flattened ansector-descendant
view of the privilege hierarchy in a specially maintained table like
it is done in the case of the context hierarchy.
-
Now for the third hierarchy playing a promiment role in the permission system. The party
data model is set up as follows.
-
+
create table parties (
party_id
not null
@@ -326,9 +325,9 @@
group_name varchar2(100) not null
);
- Recall that the grantee_id column of the
+ Recall that the grantee_id column of the
acs_permissions table references
- parties.party_id.
+ parties.party_id.
This means that you can grant a privilege on an object to a party, person, user, or group.
Groups represent aggregations of parties. The most common scenario that you are likely
to encounter is a group that is a collection of users, although you could also
@@ -339,7 +338,7 @@
a group named Pranksters, you can assign membership to Pete,
Poly, and Penelope. The fact that these users are members of the
Pranksters group will be recorded in the
- membership_rels and acs_rels tables:
+ membership_rels and acs_rels tables:
create table acs_rels (
rel_id
@@ -369,9 +368,9 @@
check (member_state in ('approved', 'banned', 'rejected', 'deleted'))
);
- The acs_rels
+ The acs_rels
table entries would look like so:
- Table�11.10.� | rel_type | object_one | object_two |
|---|
+ Table�11.10.� | rel_type | object_one | object_two |
|---|
|
membership_rel
|
Pranksters
@@ -395,8 +394,8 @@
of Pranksters. We say that the Pranksters group
is composed of
groups Merry Pranksters and Sad Pranksters. This
- information is stored in the acs_rels
- and composition_rels tables.
+ information is stored in the acs_rels
+ and composition_rels tables.
create table composition_rels (
rel_id
@@ -405,8 +404,8 @@
);
The relevant entries in the
- acs_rels look like so.
- Table�11.11.� | rel_type | object_one | object_two |
|---|
+ acs_rels look like so.
+ Table�11.11.� | rel_type | object_one | object_two |
|---|
|
composition_rel
|
Pranksters
@@ -472,17 +471,17 @@
primary key (member_id, group_id, rel_id)
) organization index;
- The group_component_index table stores a flattened representation of the
- group composition hierarchy that is maintained in sync with the acs_rels
- and composition_rels tables through triggers.
+ The group_component_index table stores a flattened representation of the
+ group composition hierarchy that is maintained in sync with the acs_rels
+ and composition_rels tables through triggers.
- As far as the group_member_index table goes, I am not sure I understand its
+ As far as the group_member_index table goes, I am not sure I understand its
purpose. It maintains group-member relationships that are resolved with respect
to group composition. Note that information stored in
- group_member_index can be trivially derived by joining
- membership_rels,
- acs_rels,
- and group_component_index. Here
+ group_member_index can be trivially derived by joining
+ membership_rels,
+ acs_rels,
+ and group_component_index. Here
is a view that does it. (This view is not part of the OpenACS Kernel data model.)
create or replace view group_member_view
@@ -507,8 +506,8 @@
mr.rel_id = r.rel_id
and r.object_id_one = gci.component_id;
- A heuristic way to verify that group_member_view is essentially identical
- to group_member_index is to compute the
+ A heuristic way to verify that group_member_view is essentially identical
+ to group_member_index is to compute the
symmetric difference between the two:
select
@@ -531,12 +530,12 @@
The query returns no rows. The important point is, if we
have a flattened view of the composition hierarchy -- like one provided
- by the group_component_index table --
+ by the group_component_index table --
membership relationship resolution can be computed trivially with no hierarchical
queries involved. There is no need to keep the view in a denormalized
table, unless doing so results in substantial performance gains.
-
- Security information is queried by calling the acs_permission.permission_p
+
+ Security information is queried by calling the acs_permission.permission_p
function in OpenACS 4.x.
create or replace package body acs_permission
@@ -563,13 +562,13 @@
end acs_permission;
The function simply queries
- acs_object_party_privilege_map,
+ acs_object_party_privilege_map,
which is a humongous view that joins three flattened hierarchies:
the context tree, the privilege hierarchy,
the party composition (and membership) hierarchy. As such,
it contains an extremely large number of rows. About
the only kind of query you can run against it is the one
- performed by the acs_permission.permission_p
+ performed by the acs_permission.permission_p
function. Anything other than that would take forever to
finish or would ultimately result in an Oracle error.
@@ -593,9 +592,9 @@
for rec in cur
loop
acs_permission.revoke_permission (
- object_id => rec.object_id,
- grantee_id => rec.party_id,
- privilege => 'foo_create'
+ object_id => rec.object_id,
+ grantee_id => rec.party_id,
+ privilege => 'foo_create'
);
end loop;
@@ -605,7 +604,7 @@
end;
/
- The acs_permission.revoke_permission function merely runs a
+ The acs_permission.revoke_permission function merely runs a
delete statement like so:
delete from
@@ -615,9 +614,9 @@
and grantee_id = revoke_permission.grantee_id
and privilege = revoke_permission.privilege;
- Note that in the above example, acs_permissions had only
+ Note that in the above example, acs_permissions had only
one entry that needed to be deleted:
- Table�11.12.� | object_id | grantee_id | privilege |
|---|
+ Table�11.12.� | object_id | grantee_id | privilege |
|---|
|
default_context
|
registered_users
@@ -626,8 +625,8 @@
|
The above script would never get around to deleting this entry because it had
to loop through a gazillion rows in the humongous
- acs_object_party_privilege_map view.
- Appendix: Various View Definitions
+ acs_object_party_privilege_map view.
+ Appendix: Various View Definitions
create or replace view acs_object_party_privilege_map
as
select
@@ -690,4 +689,4 @@
container_id
from
group_member_index;
- |
|
|
|
|
|
