cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Romayev <>
Subject Re: role-based access to pages and parts of pages - ideas?
Date Fri, 09 Jan 2004 15:43:59 GMT

Here are a few ideas that I've used and I think you
might benefit from them as well:

I like to think that each page is assembled of
portlets, e.g. navigation portlet, form portlets,
information portlets, related links portlets, etc. 
The pages are internal (i.e. protected) and external. 
This is how I break up my sitemap based on this logic:

1.  I match for internal pages and external pages
(just like Stefan suggests), for example internal/*
and protected/*.  This should make your authentication
matching easier.  My page pipeline simply aggregates
portlets and applies a layout stylesheet to place them
within the page.

2.  I have separate pipelines for portlets and what I
call resources (see below).  These pipelines are
"internal", so I don't need to worry about security
for them.

3.  I have a separate pipeline for portlets, which
matches on */*.portlet, i.e.
<module>/<portlet-name>.portlet.  Each portlet gets
its input from a resource, which means that the
responsibility of the portlet is to do the styling.  I
then subcategories portlets based on their
presentation style:

<map:match pattern="*/*.portlet">

  <map:match pattern="*/*.form.portlet">
    <map:generate src="cocoon:/{1}/{2}.resource/>
    !-- Apply form specific styling -->

  <map:match pattern="*/*.table.portlet">
    <map:generate src="cocoon:/{1}/{2}.resource/>
    !-- Apply table specific styling -->

  <map:match pattern="*/*.links.portlet">
    <map:generate src="cocoon:/{1}/{2}.resource/>
    !-- Apply related links specific styling -->


4.  My resource pipeline matches on */*.resource and
is the messiest place, since it deals with the fact
that  each resource comes from different sources and
needs different types of transformations.

So I have 4 sitemaps:
- sitemap.xmap
- pages.xmap
- portlets.xmap
- resources.xmap

I really like Stefan's idea of authorization
transformer, which filters data based on your
permissions.  Have you thought of contributing it to
the project?

Helma, I don't suggest you implement the above
solution, you know your site best and it might not
work for you.  However, I hope it gives you ideas for
what types of things you need to be thinking about
when designing your sitemap.  I know refactoring would
be a big task, but I usually find it worthwhile.

Hope this helps,

--- Stefan Klein <> wrote:
> Helma,
> I'll tell you a little more about me approach (it
> was a rather rough
> summary I gave you). Maybe some of the problems you
> see are solved
> already.
> > 1. I have various roles (between 5 and 10) which
> overlap in access
> > authentication, so every pipeline would need to
> check for several roles
> > and if I need to add extra roles I need to revisit
> every pipeline. :-(
> I don't actually check for roles, but use resources
> as another level of
> abstraction:
> resources are what we want to protect (e.g. certain
> urls, combinations of
> urls and request-params, whatever)
> roles have access to resources
> users have roles
> E.g. you have a type of patient record that can be
> accessed by nurses and
> doctors. So you have roles "nurse" and "doctor" both
> of which can access
> the resource "patient record x".
> Now the authorization goes like this:
> user smith requests access to "patient record x".
> The authorizer checks
> which roles have access to "patient record x" and
> then whether user smith
> has any of these roles. So in our case smith could
> be doctor or nurse and
> would be granted access either way.
> The sitemap still looks the same, but instead of a
> role you pass a
> resource to the action.
> > 2. My sitemap is growing rapidly and by adding
> enormous amounts of
> > comment I'm trying to keep it clear, but I find it
> more and more
> > difficult to find what I'm looking for. So
> configuring authorisation in
> > the sitemap is not really my idea of keeping it
> clear and separated.
> > 3. I want a general way of handling several pages,
> i.e. with a minimal
> > number of pipelines. If in future I add a page, I
> want it to be
> > integrated without touching the sitemap. I was
> thinking of adding
> > access rules to the source of the form, but that
> would also spread the
> > authorization. :-(
> I agree with Alex, it might be useful to have a look
> at your sitemap, if
> we can. Authorization generally shouldn't add a lot
> of overhead.
> What I do is use sub-sitemaps for protected areas.
> So in my main sitemap
> I have
> <map:match pattern="protected/**">
>    <map:act type="authorize">
>      <map:parameter name="resource" value="{1}">    
>      <map:mount uri-prefix="protected"
> src="protected/sitemap.xmap"
> check-reload="true"/>
>    </map:act>
> </map:match>
> This way any request of form //host/protected/*
> needs authorization. The
> autorization is done based on the requested url (the
> url after protected/
> is actually the authorization resource). So in our
> example above the
> request could be //host/protected/patient-record-x.
> The authorizer than
> checks (in my case against a database) if any of the
> user's roles has
> access to that resource. If so, the request is
> passed on to the protected
> sitemap. 
> Notice, that you will never have to change anything
> about this to add new
> pages to the protected sitemap. You only need to
> make sure the user's
> roles have access to the new resource (in my case,
> by adding an entry in
> the database). The protected sitemap stays clear of
> authorization
> functionality.
> > 4. One or more roles may have more
> features/information on a page than
> > others. This would mean I have to customize role
> checking for every
> > page item. :-(
> For that I wrote a transformer. My pages contain
> statements of the form
> <cms:auth role="doctor">
> <content.../>
> </cms:auth>
> On encountering a cms:auth tag the transformer
> checks whether the user
> has that role. If so, it passes on the enclosed
> content. If not, it
> filters it.
> Stefan
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Alex Romayev
Software Architect

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

View raw message