On 9/7/06, Joern Nettingsmeier <[EMAIL PROTECTED]> wrote:
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> hi everyone!
>>
>>
>> looking at thorsten's ac work i realized that we still have
>> hierarchical "storage" for the policies.
>
> Do we want to protect URLs, or documents?
> For example - if you exchange the document of a sitetree node (=URL),
> should the policy be moved with the document, or stay attached to
> the node?
currently, we are protecting nodes (or branches in the sitetree), and i
think that's ok. it makes inheriting permissions easier to handle. i
don't see a pressing need to have per-resource access control that is
embedded in the document metadata.
the most common usecase in web publishing is that of an "intranet",
which basically means: everything you dump in this subtree is protected.
fine with me, and quite intuitive.
>> although we have gotten rid of that for the content after the
>> introduction of uuids, we still need to shuffle directories around for
>> the ac "repository" whenever a user changes the sitetree.
>>
>> what's the plan to get rid of that? would it be feasible to integrate
>> the url/subtree policies into the sitetree? it would be nice to debug
>> (everything in one place), and we can lose the horrible directory
>> structure...
>
> I wouldn't add specific elements / attributes to the site structure.
> How about site node meta data?
since i think we need tree-based (as opposed to document-based) ac, the
sitetree.xml is the natural place for it imho.
and if you move a node, the ac moves along (except for inherited stuff
of course).
FWIW, I work with a commercial system that can applies ac at 2 levels:
the site tree node and the assets, where assets are things *on* a
page (the actual content), the idea being that a page can have
multiple assets on it (and the page itself isn't ac-controlled at
all). Anyway, this 2-level ac setup works very nicely, because
generating the site tree is quick/easy (you don't have to follow the
links to see if the node should be displayed), and you have maximum
flexibility in giving different groups different navigation views to
the content.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
