| B
object_id=20
@@ -117,23 +117,23 @@
This can be represented in the
acs_objects table
by the following entries:
- Table�5.3.� | object_id | context_id |
|---|
| 20 | 10 | | 30 | 10 | | 40 | 20 | | 50 | 20 | | 60 | 30 |
+ Table�5.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�5.4.� | object | grantee | privilege |
|---|
| A | Joe | read |
+ Table�5.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�5.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�5.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
@@ -204,7 +204,7 @@
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�5.6.�
+
Table�5.6.�
A
object_id=10
readable�by�Joe
@@ -232,7 +232,7 @@
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�5.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�5.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,7 +241,7 @@
privilege to which the first four privileges are tied. To give
a more detailed example, the Bboard privileges are structured
as follows.
- Table�5.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�5.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:
@@ -287,7 +287,7 @@
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
@@ -371,7 +371,7 @@
The acs_rels
table entries would look like so:
- Table�5.10.� | rel_type | object_one | object_two |
|---|
+ Table�5.10.� | rel_type | object_one | object_two |
|---|
|
membership_rel
|
Pranksters
@@ -406,7 +406,7 @@
The relevant entries in the
acs_rels look like so.
- Table�5.11.� | rel_type | object_one | object_two |
|---|
+ Table�5.11.� | rel_type | object_one | object_two |
|---|
|
composition_rel
|
Pranksters
@@ -617,7 +617,7 @@
Note that in the above example, acs_permissions had only
one entry that needed to be deleted:
- Table�5.12.� | object_id | grantee_id | privilege |
|---|
+ Table�5.12.� | object_id | grantee_id | privilege |
|---|
|
default_context
|
registered_users
|
|
|
|
|
|
|
|
|