On 11/25/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> 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
>
>
I see what you mean. No sense in reinventing the wheel. I can always
have my managed bean properties be proxies to chains if I wanted to
use the design features that chain offers.
so my isManagerOfAppropriateDepartment() would lookup the
isManagerOfAppropriateDepartment catalog and that would execute
isManager and isAppropriateDepartment commands passing a suitable
Context.
Thanks.
