Daniel Fagerstrom wrote:
> Maybe I should have stated my asumptions, (instead of just having them in my
> mind while writing ;) ):
>
> 1. In many applications it is your DB content or your documents that is the
> natural unit of protectection, rahter than their various combinations and
> presentation.
Hmmm, what about aggregation? what about a web application? the only
meaninful unit of protection I see is the URI and this doesn't require
component-granular AC.
> 2. To be able to handle protection of your content, a CMS would be nice to
> have.
Of course, but this has very little to do with Cocoon managing AC
directly: AC at the editing level will very likely *not* be performed by
Cocoon but by some higher logic since it resides in a totally different
concern island (at least, that's how I see it)
> 3. If we let a CMS handle the content that Cocoon gives web access to I
> would rather like to know before I compose and start a pipeline, if I will
> be allowed to excecute all its part, than getting an access violation
> exception during its excecution.
In my ideal architecture, a CMS will make transparent all the content
that you don't have access to.
So, yeah, Cocoon needs some way of obtaining use information (but
authentication) but I don't see any reason to have lower-level
granularity directly in Cocoon.
> My conclusion is that in the context of the above assumptions is that:
> Cocoon should be able to derive the access rights for a request URI from
> access rights of its participating components.
> This is analouge to how
> cocoon derives if a pipeline is cachable from its components cachability.
Ok, now I see where you are coming from...but I can't find myself
resonating with this... what do others think?
> <snip/>
> > > Pipeline based AC is useful (and maybe the only realistic alternative)
> > > for operations like updates in DB, but does not seem to scale well.
> >
> > Granted but this is by design: pipelines are 'groups of URIs that happen
> > to share concerns'... so applying attributes to pipelines (like AC for
> > example) is a highly granular operation, but rightly so (IMO, anyway).
> hmm ... seem reasonable, maybe I should wait and see if it becomes a
> scalability problem in practice, before trying to find a cure. Maybe it is
> more about distributing administration resposibilties.
Yes, I agree that we should not cure something that we don't know it's
ill.
> > > The only concept that
> > > corresponds to WebDAV actions is the cocoon-action request parameter
> > > for action sets.
> >
> > Wrong! These are totally different things and should not be mixed just
> > because they happen to share the same name.
> Ok I agree, what I mean is that you might want to allow some values for a
> cocoon-action for a certain user, but not others.
Ah, this is different and I agree with you here, this might be a
desirable functionality
> <snip/>
> > > To conclude: I belive that a request URI based AC system have clear
> > > advantages compared to pipeline based AC, and that it could be added
> > > to Cocoon without effecting the contracts at all. I also think that
> > > the "correct" way of handling security is a resource based system, and
> > > that a such would need to affect the inner workings of Cocoon.
> >
> > Hmmm, interesting vision.
> >
> > Just one question: what about errors? how do you handle them?
> What errors :) Maybe I missed something, the only new category of errors
> should be access violation errors, it might be practical to trap those in a
> special error handling rule so that the user e.g. can be redirected to a
> login page.
well, it might be more complex than this: don't assume your users know
what you know about the application. If something doesn't work, you have
to tell him why and how to fix this before jumping back on a login page.
> > how about aggregation? how about selectors?
> The main idea is that you only can access an request URI if you are allowed
> to access all components that are needed to build its pipeline, so for
> agregation you just check the request URI:s for the parts. For selection it
> is more complicated, the selection of components for the pipeline can depend
> on the result of actions that have sideeffect. I guess that a general
> requirement is that the sitemap is so declarative that it is possible to
> draw any conclusion about its runtime behaviour, (conditioned on request
> parameters) from a static analysis of it.
Ok then, let's see: if we were to add AC semantics to the sitemap, how
would you do it?
I mean: how would you patch the current sitemap
markup/semantics/behavior?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
