Forum OpenACS Development: context_id and site nodes

Posted by Gilbert Wong on

Is the context_id of every package instance always tied to the Main Site's object? Looking at the site_nodes table and referencing the object_id column for the package instance I am interested in, I did a query on acs_objects on that object id to find what the context_id was. For instance:

select node_id, parent_id, name, object_id, tree_sortkey from 
 node_id | parent_id |   name    | object_id | tree_sortkey 
    2103 |           |           |      2078 | /00
    2104 |      2103 | acs-admin |       325 | /00/00
    2105 |      2103 | doc       |       931 | /00/01
    2106 |      2103 | api-doc   |       357 | /00/02
    3202 |      2103 | surveys   |      3204 | /00/03
    3205 |      2103 | store     |      3207 | /00/04
    3310 |      3202 | notes     |      3337 | /00/03/00
    3342 |      2103 | csms      |           | /00/05
    3343 |      3342 | forums    |           | /00/05/00
    3339 |      3310 | test      |      3346 | /00/03/00/00
 select package_id,package_key,instance_name from apm_packages;

 package_id |       package_key       |        instance_name        
        381 | acs-bootstrap-installer | OpenACS Bootstrap Installer
        393 | acs-content             | ACS Content
        694 | acs-templating          | ACS Templating
        710 | acs-util                | ACS Utilities
        739 | acs-mail                | ACS Mail
        748 | acs-notification        | ACS Notification
        841 | acs-tcl                 | ACS Tcl
        931 | acs-core-docs           | ACS Core Documents
       1285 | acs-workflow            | ACS Workflow
       1415 | acs-content-repository  | ACS Content Repository
       1449 | acs-messaging           | ACS Messaging
       2077 | skin                    | Skin
        146 | acs-kernel              | ACS Kernel
       2078 | acs-subsite             | Main Site
        325 | acs-admin               | ACS Administration
        357 | acs-api-browser         | ACS API Browser
       2129 | acs-geo-tables          | ACS Geo Tables
       3204 | simple-survey           | PG Central Surveys
       3207 | ecommerce               | PG Central Store
       3337 | notes                   | Note Writer
       3346 | notes                   | Subnote Writer
select object_id, context_id from acs_objects 
where object_id in  (3337,3346,3204);

 object_id | context_id 
      3204 |       2078  (surveys)
      3337 |       2078  (notes)
      3346 |       2078  (test)

The reason I chose these two objects is because they were sub-urls of each other.

  ^-- notes
       ^-- test

Should APM set the context_id's like this: test set to 3337 (notes), notes set to 3204 (surveys), and surveys set to 2078 (main site)? I would like to set permission based on the URL hierarchy. To me it makes sense for the packages to inherit their default permissions from the parent_url and not default to the main site. Have I missed something here?

Posted by Roger Williams on

I have been looking into this extensively to try to fix some bugs in ACS4Tcl. There seems to be little consensus on the semantic meaning of acs_objects.context_id. The best reference (for issues, that is) I have found is here, though it is dated.

In the last couple of days, I have been staring at this from acs-objects-create.sql:

comment on column acs_objects.context_id is '
 The context_id column points to an object that provides a context for
 this object. Often this will reflect an observed hierarchy in a site,
 for example a bboard message would probably list a bboard topic as
 it''s context, and a bboard topic might list a sub-site as it''s
 context. Whenever we ask a question of the form "can user X perform
 action Y on object Z", the acs security model will defer to an
 object''s context if there is no information about user X''s
 permission to perform action Y on object Z.

In the context (sorry 😊 of the above reference, the Permissions Explained document, and reading the code for several packages, the possible conflict between the logical (i.e. site) hierarchy and the security hierarchy is focused on this acs_objects attribute. Note however, that this conflict, while possible, is not forced by the data model design.

Specifically, if the logical and security hierarchies are the same, all will be right with the world. I think this is true, but I cannot prove it yet. And they probably do not have to be the same, just one must be a strict subset of the other.

The thread called Implicit use of Context_id=Package_id of the above bboard post is the most illuminating for me, thus far.

My apologies, since this mostly just raises more questions..


Posted by Don Baccus on
My understanding is that context_id was originally meant to be a security (permissions) context only, but that various package implementors within aD found it convenient to use context_id as a parent link used to model the site hierarchy.

The thread Roger points to would indicate there was never any consensus over the issue.  My guess is that you'll find inconsistency from package to package.

This looks like a research item, a good solution should be found but I don't think it will happen by the time the port's finished.

4: Permissions hierarchy (response to 1)
Posted by Titi Ala'ilima on
At Ybos, we've tried to keep context_id mostly as a permissions thing. We've added a parameter into the acs-subsite package which allows you to choose to default context_id to the package_id whose site-map you're using (the 'classic' method) or to the nearest ancestor providing subsite services. This will be released soon hopefully.

Anyway, there could be room for another inheritance scheme, not restricting it to subsite-type apps.