cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Access Control (was [RT] Cocoon as OS)
Date Fri, 08 Feb 2002 17:50:17 GMT
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
> > > 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

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message