> 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_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
