On 11/25/05, Ryan Wynn <[EMAIL PROTECTED]> wrote:
>
> On 11/25/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > On 11/25/05, Ryan Wynn <[EMAIL PROTECTED]> wrote:
> > >
> > > I was doing some work on enabling declarative component level render
> > > permissions alongside shale-clay. What I came up with was to use the
> > > postProcessCreateComponent pluggable command in clay's chain. In this
> > > command I check the current component for an attribute called
> > > 'renderIfRoleIn'. This attribute is designed to be a comma delimited
> > > list of user roles. I then check if the user's role is in this list
> > > using request.isUserInRole(nextRole); if not I set the rendered
> > > property of the component to false.
> > >
> > > I was thinking this might be something that could be useful at a shale
> > > or clay level. If not at that level then maybe a shale-xxx.jar
> > > plugin. Any thoughts?
> > >
> > > Ryan
> >
> >
> > Interesting idea ... but I wonder if we are trying to bury too much
> logic in
> > the view tier with this approach?
> >
> > I'm just thinking that the next person who comes along will say "it's
> not
> > just user roles that matter for me, it's whether the user is the manager
> of
> > a particular department whose detailed information I'm about to display"
> --
> > a concept that I would not assume is represented as an explicit role (in
> > terms of container managed security constraints).
> >
> > Wouldn't it be more general to just bind the rendered property of the
> > component to a boolean function in your backing bean, which did the
> > appropriate calculations? One could certainly write some simple utility
> > functions that did lookups based on arbitrary sets of roles (which would
> > have to be encoded into the component somehow), or perhaps better would
> be a
> > set of predefined methods for all the interesting combinations
> (isManager(),
> > isUser(), isLoggedOn(), ...). The implementations of these methods can
> > implement whatever state checking is relevant, which may include roles
> but
> > may also include checking other information -- and these sorts of nitty
> > gritty details are not something the page author should have to be
> worried
> > about.
> >
> > Craig
> >
> >
>
> Yeah, I agree with you Craig, it will invevitably become more complex.
> I just thought that a good percentage of the cases with be based
> simply on explicit roles.
>
> For these more complex cases it might be nice to be able to plug into
> an existing chain that is designated for this rendering purpose. For
> example the default behavior of the chain is to keep the rendered
> property as-is. But if the user plugs in a chain at a specific entry
> point then rendered could be overriden.
>
> For example in your scenario, it might be nice to be able to
> 'chainize' in commands the isManager, isManagerOfDepartmentX,
> isViewingDataX requirments. Only to benefit from the separation of
> concerns that chain offers.
>
> I guess from the framework point of view I would be asking to consider
> an entry point.
I guess here is where I'm wondering why we need a framework to accomplish
this at all, given what JSF already provides? Consider something like this,
using JSP syntax:
<h:panelGrid ... rendered="#{
securityChecks.managerOfAppropriateDepartment}">
... components to conditionally display ...
</h:panelGrid>
Of course, if you were using Clay, you'd use some defined equivalent of
<h:panelGrid>. But the key point is that you don't *have* to resolve all
the attributes to literal values as part of the "configure the rendered
components" process that Clay does when it parses the template ... simply
pass on the value binding expression on, so that it gets evaluated by the
component itself when the time is right. The
isManagerOfAppropriateDepartnement() method would check the departmentId
field of the Manager bean against the department id of the department you're
trying to display info for (so the method itself takes no parameters).
This way, you can localize your security checks into a managed bean (or make
it the page bean that corresponds to the page, if the issues are unique to
that page), with the full capability to configure the security bean's
behavior through managed bean property settings.
This strategy also works well for both JSP and Clay presentation
technologies, so you can use either (or both) in your application, as you
choose.
Thanks,
> Ryan
>
Craig
