cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [C2] (hopefully) last sitemap major changes
Date Mon, 03 Jul 2000 21:55:09 GMT
Nicola Ken Barozzi wrote:

> > > Anyway security is much bigger than something to put in the sitemap.
> > > I am still confused on how it could implemented.
> > > Are there any ideas on how C2 must deal with security issues anyone?
> >
> > I think the nearest we get in the first round is a FileAuthenticationChooser.
> > It will basically use a kind of .htaccess file in each directory, and then "grant
access"
> > to that subpipe.
> >
> > I have also been lurking with the idea of a ResourceAuthenticationChooser, which
would
> > work on the Resource abstraction in the sitemap.
> 
> It would be great!
> In my point of view (correct me if 'm wrong) it is something like (not exact):
> classes : interfaces = file : recource
> So for resources:
> +2

hmmm, not really. It's more related to AOP than OOP.... but in general,
yes, the idea of a "resource" is more abstract than a "file".
 
> > Stefano/Giacomo, since I am looking into these Choosers at the moment, how do they
get a
> > reference to the whole Cocoon context, and such thing as resource/path in process
and so
> > forth.
> >
> > > > > How does it relate to the contracts?
> > > >
> > > > Which contracts? Sorry, I lost you here.
> > >
> > > The contracts between programmers, content creators, etc.
> > > Who should be in charge of security?
> >
> > Site managers of course. Content creators and Style/Graphics people have no clue,
> > programmers never care, so...
> >
> 
> Ok... mmm.
> Well, in an organization there are many different levels, and different
> people manage security for different contexts.

This is why the sitemap is cascaded.

> For example, there is a planning division, and the manager has the need of both
> authoring reports and setting access privileges for them. But he must not deal with
> security of other domains...

right.

> I guess that with your solution it could be ok:
> the site manager gives him access to only some directories, where he puts the
> files and the security files. Ok.
> But how about maintaining a security "database" that is dispersed in all the file system?
> I don't know the internals of .htaccess are but if they specify only the constraits (roles)
> needed as I think they do it could be ok.

Also keep in mind Cocoon is not a web server. You still have Apache up
higher if you need security in other locations of your URI space.

For the locations that are mapped to Cocoon, keep in mind you can have
different Cocoon instances mapped to different URI or virtual hosts.
Each one with different security capabilities due to Tomcat security
managers and custom classloaders.

Then, when you need to partition Cocoon behavior (sort of
security-views), you can do something like

 <match type="uri" pattern="*">
  <choose type="role">
   <when test="administrator">
    <mount src="file:///home/www/admin.xmap"/>
   </when>
   <when test="user">
    <mount src="file:///home/www/user.xmap"/>
   </when>
   <otherwise>
    <mount src="file:///home/www/guest.xmap"/>
   </otherwise>
  </choose>
 </match>

with selective mounting, separating the working contexts from web
administrators with different skills.

> Then there is another point. (using the same example)
> Let's say that you need to limit portions of the report to users, and that this report
is
> linked in another file: it would be nice that the link would not be shown if the privileges
> needed inside the file were not to be satisfied by the current user. It would need a
special
> link tag that nows about other file restrictions.

No, you need to trigger a transformation in the sitemap based on
security parameters.

> Now I am duplicating the security info using my tablib security tag twice, but I have
to
> keep both up to date.

Right. The sitemap should have control of all these things, demanding
complex logic to programmers.

> Any ideas?
> Today's innovation is tomorrows legacy. (just reminding myself of it)

No shit. This is why we want to get this sitemap thing right (or, at
least, best that we can) and make it simple but nor simpler.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message