cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@supereva.it>
Subject Re: [C2] (hopefully) last sitemap major changes
Date Mon, 03 Jul 2000 08:19:09 GMT
----- Original Message ----- 
From: "Niclas Hedhman" <niclas@localbar.com>

> Nicola Ken Barozzi wrote:
> 
> > > > Another thing is security.
> > >
> > > yep, "another thing".
> > >
> > > > Now I made my taglib for security but why not specify it in the sitemap?
> > >
> > > For example?
> >
> > The web.xml in J2EE is similar in some ways to the sitemap; in it you can specify
> > security constraints for web resource collections.
> >
> >     <security-constraint>
> >       <web-resource-collection>
> >          <web-resource-name>Protected Area</web-resource-name>
> >   <!-- Define the context-relative URL(s) to be protected -->
> >          <url-pattern>/restricted/*</url-pattern>
> >   <!-- If you list http methods, only those methods are protected
> >   <http-method>DELETE</http-method>
> >          <http-method>GET</http-method>
> >          <http-method>POST</http-method>
> >   <http-method>PUT</http-method> -->
> >       </web-resource-collection>
> >
> > Here you limit HTTP methods in a url pattern.
> > In C2 you could limit views.
> >
> > 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 

> 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.
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... 
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.

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.
Now I am duplicating the security info using my tablib security tag twice, but I have to
keep both up to date.
Any ideas?
Today's innovation is tomorrows legacy. (just reminding myself of it)

Ken



Mime
View raw message