| B
object_id=20
@@ -117,23 +117,23 @@
This can be represented in the
acs_objects table
by the following entries:
- Table 7.3. | object_id | context_id |
|---|
| 20 | 10 | | 30 | 10 | | 40 | 20 | | 50 | 20 | | 60 | 30 |
+ Table�10.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 7.4. | object | grantee | privilege |
|---|
| A | Joe | read |
+ Table�10.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 7.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�10.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
@@ -163,9 +163,9 @@
an index-organized
table, which means it is substantially optimized for access by primary key.
Number two, as the above computations suggest, the size of the table
- grows polynomially
+ grows polynomially
with respect to the average number of descendants that an object
- has, and exponentially
+ has, and exponentially
with respect to the depth of the context tree.
The acs_object_context_index is kept in sync with the
@@ -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 7.6.
+
Table�10.6.�
A
object_id=10
readable�by�Joe
@@ -228,11 +228,11 @@
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 7.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�10.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 7.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�10.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:
@@ -284,10 +284,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
@@ -371,7 +371,7 @@
The acs_rels
table entries would look like so:
- Table 7.10. | rel_type | object_one | object_two |
|---|
+ Table�10.10.� | rel_type | object_one | object_two |
|---|
|
membership_rel
|
Pranksters
@@ -393,7 +393,7 @@
Another way of building up groups is by adding subgroups. Suppose
we define Merry Pranksters and Sad Pranksters as subgroups
of Pranksters. We say that the Pranksters group
- is composed of
+ is composed of
groups Merry Pranksters and Sad Pranksters. This
information is stored in the acs_rels
and composition_rels tables.
@@ -406,7 +406,7 @@
The relevant entries in the
acs_rels look like so.
- Table 7.11. | rel_type | object_one | object_two |
|---|
+ Table�10.11.� | rel_type | object_one | object_two |
|---|
|
composition_rel
|
Pranksters
@@ -535,7 +535,7 @@
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
function in OpenACS 4.x.
@@ -617,7 +617,7 @@
Note that in the above example, acs_permissions had only
one entry that needed to be deleted:
- Table 7.12. | object_id | grantee_id | privilege |
|---|
+ Table�10.12.� | object_id | grantee_id | privilege |
|---|
|
default_context
|
registered_users
@@ -627,7 +627,7 @@
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
+ Appendix: Various View Definitions
create or replace view acs_object_party_privilege_map
as
select
@@ -690,4 +690,4 @@
container_id
from
group_member_index;
- |
|
|
|
|
|
|
