A little more tracing reveals that when children are
added to a
structure all concrete decoration classes are given a chance to do
something to the child. The security decorator copies from the parent,
which in turn triggers the creation of a security descriptor, using the
current context for user and group, on the page.
Correct.
I also learned that the children of a PRStructure are
kept in a child
decorator; that was not what I would have guessed.
Yes, this separates all the "children" behavior into a separate object
and allows all structures to have children or not. This was one of the
major annoyances in SmallWiki the predecessor of Pier, where children
were only allowed in folder.
You can only
apply the security decorations to subclasses of
PRStructure (these are the objects that represent a unique URL or
entry point into your application), not to arbitrary objects (out of
the box, at least).
I'm thinking of having a page with a central area that gets swapped
according to what the user is doing; the other material on the page
would stay. Does that mean there's really only one security decoration
that is relevant? Or does it mean the children are individually
addressable (e.g., elements of a list)?
If you have a page that embeds some of its child-pages using the
+child1+ syntax, chilld1 is only embedded if the user has view
permission on child1 as well. So yeah, sometimes multiple permissions
from different places come into play.
Also, I wonder if I need any security other than
ensuring someone is
logged in. A user will only be presented links to stuff that is
relevant (and allowed) for them. Does adding security to the objects
add any additional security (e.g., perhaps against attempts to
manipulate the URL)?
Again, you cannot add security to arbitrary objects, just to
structures that map to particular URLs.
For example for this software engineering course <http://ese.unibe.ch>
there are pages that only the assistants can see and edit (for the
organization of the course), there are pages that only specific groups
of students can edit (for the student teams), there are personal pages
that you can only see when logged in and only a particular student can
edit (for the personal pages), there are pages that all students can
see and edit (for feedback), etc.
Finally, in case I do need security, is the ACL based
framework still
around? It's probably more appropriate for the scenarios I have in
mind.
The ACL based framework is more powerful, indeed. I don't think it was
used recently and would probably need some updates to work in the
latest version of Pier.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch