Forum OpenACS Development: Re: Re: XoWiki 0.31 problem with deleted pages

Collapse
Posted by Gustaf Neumann on
Just to be sure: you create a page p1, then a page p2 with a reference to p1, and you view p2. Then you delete p1 and view p2 again, you get the error. Seems, i have accidentally fixed this problem while working on xowiki::File.

If you need the fix soon, i can commit the current snapshot, otherwise i need a little time for polishing [[image:dave.png]] and [[file:docu.pdf]]. In the current snapshort, binary files are sometimes altered during download...

No need for a hasty commit Gustaf. We will just avoid deleting files till you have time for the polish (restarting the server fixed the problem for now).

I have an unrelated question about permission granularity. We have a need to be able to add specific permissions for individual pages through the UI.

There are many use cases that come to mind, but the one that is relevant to us right now has to do with wanting to hide certain pages from certain users for an internal study we are planning. A more general use case is wanting to protect a controversial page from general edit.

What are your plans in this direction? How should we implement this?

Thanks,
Carl

P.S. We are benefiting greatly from your work.

I am not sure, if "hiding pages" and "protecting pages" is the same issue. Hiding pages is a rather workflow issue, saying when a page should be released to the "public", expressing a certain state of a page, while protecting certain pages is clearly a permission issue. permissions are quite slow in openacs, permissions on the object level are not so nice for caching either (compared to permissions on the package_ids or folder_ids). The policy are going into this direction, athough they have no userinterface yet. i will think about this...

Note, that this effects rss + weblog + search + visibility of links (references between pages) as well. The easiest approach seems to me currently to provide a separate xowiki instance for the "internal study" and merge these pages later into the public set when appropriate. import/export of xowiki can be easily extended to work between xowiki instances.

Collapse
Posted by Gustaf Neumann on
Hi Carl,

i have just committed a small experimental enhancement to xowiki 0.36. The new ::xowiki::policy3 allows for checking of individual pages (policy 1 and 2 check only rights on the package). When policy 3 is activated the admin page shows an additional column for managing permissions of individual pages. The aggregating views don't evaluate the
permissions for the time being.

This approach is already fine for protecting individual pages (prohibiting edits, no problems with aggregations), but i am not sure whether this is the right approach to hide e.g. work in progress. Permission checking is quite expensive in openacs. Checking on the package level scales much better, since this is much better for caching, when many user and many pages are involved. Checking on instance level needs a space of packages * users * privileges. For checking on instance level, the needed space is much larger (objects * users * privileges). Furthermore, caching does not work well, since the probability that the same user e.g. reads the same object twice in a session is much smaller the that the same user reads two different objects form the same package in a session.

In learn@wu, we are using an "active" flag, which hides pages from non-admins. This flag can be efficiently checked in all sql queries with more or less no extra cost.

Btw, the policy manager allows as well to use for certain operations on certain pages mixed kinds of checking. Depending on the object type or a predicate satisfiable from the page instance one can use for certain operations package level or instance level checking.

Below is for reference policy3. It differs from policy2 essentially by using the attribute item_id instead of package_id for checking. It can be activated form the package parameter page (conveniently reachable from the admin pages).

best regards
-gustaf


   Policy policy3 -contains {
     #
     # we require side wide admin rights for deletions
     # we perform checking on item_ids for pages.
     #
  
     Class Package -array set require_permission {
       reindex {{id admin}}
       rss none
       delete swa
       edit-new {{{has_class ::xowiki::Object} id admin} {id create}}
     }
  
     Class Page -array set require_permission {
       view {{item_id read}}
       revisions {{item_id write}}
       edit {{item_id write}}
       make-live-revision {{item_id write}}
       delete-revision swa
       delete swa
       save-tags login
       popular-tags login
     }
  
     Class Object -array set require_permission {
       edit {{package_id admin}}
     }
     Class File -array set require_permission {
       download {{package_id read}}
     }
   }

Collapse
Posted by Carl Robert Blesius on
Excellent! There are many cases for page based permissions (a few of which I have already experienced on our installation).

I will try it out while you are away. With your guidance I would like to refine this feature so it is flexible and works well for sites with heavy load like yours.

Collapse
Posted by Prem Thomas on

Gustaf,

I'm using xowiki 0.38 and xotcl-core 0.45 and implemented security policy 3 to set write permissions for individual pages. This works fine, but I had a problem with read permissions. All the pages on this wiki instance allow public reading without login, the intended effect. When I switch from security policy 1 to either 2 or 3, the public can no longer read the pages; login is required. I double checked the permission using the lock icon in the Administration section of xowiki and read by the public is enabled; however, I still get the login page on attempted read.

I changed the view line in policy 3 in package-procs.tcl:

Class Page -array set require_permission {
view none
...


and this allowed public reading. However, this removes all ability to limit access to other pages. Is there another way to accomplish this?

Also, perhaps because of caching, changes to the tcl code in the file above, were not reflected in the site unless I restarted AOLserver.

Thank you for all the work you've put into this very useful package.

Collapse
Posted by Gustaf Neumann on
permission checked forced the user to login for all checks based on object ids. I have changed this in a way that it first checks whether the privilege was granted to the public, and if not, it requires a login. This is more costly, but the right thing.

please check out from CVS head.

Collapse
Posted by Prem Thomas on
Thanks, Gustaf. Checked out xowiki from head and tried it, but got the following error which I think is originating from xowiki-callback-procs.tcl, line 66

invalid command name "::xowiki::Object"
    while executing
"::xowiki::Object fetch_object -object ::$folder_id -item_id $item_id"
    (procedure "require_folder_object" line 24)
    ::833 ::xowiki::Package->require_folder_object
    invoked from within
"my require_folder_object"
    (procedure "init" line 5)
    ::833 ::xowiki::Package->init
    ::xowiki::Package ::xotcl::Class->create
    invoked from within
"my create ::$package_id -url $url"
    (procedure "require" line 8)
    ::xowiki::Package ::xo::PackageMgr->require
    invoked from within
"my require -url $url $package_id"
    (procedure "initialize" line 21)
    ::xowiki::Package ::xo::PackageMgr->initialize
    invoked from within
"::xowiki::Package initialize -ad_doc {

  This is the resolver for this package. It turns a request into
  an object and executes the object with the ..."
    (file "/usr/local/share/topaz/packages/xowiki/www/index.vuh" line 2)
    invoked from within
"source [ad_conn file]"
    (procedure "rp_handle_tcl_request" line 3)
    invoked from within
"$handler"
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
                $handler
            } ad_script_abort val {
                # do nothing
            }"
    invoked from within
"rp_serve_concrete_file [ad_conn file]"
    (procedure "rp_serve_abstract_file" line 60)
    invoked from within
"rp_serve_abstract_file "$root/$path""
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
            rp_serve_abstract_file "$root/$path"
            set tcl_url2file([ad_conn url]) [ad_conn file]
            set tcl_url2path_info..."

Collapse
Posted by Gustaf Neumann on
Since I got no fast feedback from thomas and i am leaving tomorrow for a short vacation, a short diagnosis, that might help some other people as well:

If one sees errors like this, please check the following items

  • Make sure, that acs-bootstrap-installer/bootstrap.tcl is up to date (it should include loading of the xotcl-core *init-files.
  • on cvs updates, it seems to happen that not all files are updated correctly. In the case of Thomas, it looks like the file xotcl-core/tcl/05-db-procs.tcl was missing.
The new versions of xowiki (in CVS head) need in most cases the new versions of xotcl-core from cvs head as well (it has the dependencies set). The dependencies are only checked on upgrades. If one simply updates the files, and reloads it, the dependencies are not checked...
Collapse
Posted by Prem Thomas on

As Gustaf notes above, the fix for my problem involved cvs updates of two packages, xotcl-core and acs-bootstrap-installer, on which xowiki depends. With this done, the error above disappeared.

Security policy3 for xowiki now works perfectly with permission setting on individual pages; pages with public read permission now do not ask for login prior to read.