myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cagatay Civici" <cagatay.civ...@gmail.com>
Subject Re: s:secure
Date Wed, 16 Aug 2006 14:31:40 GMT
Hi Mike,

Yes you are right about the limitation of EL.

The alternative solutions you provided can definitely solve the security
problem but it all depends on the myfaces user to be implemented.

My point is to provide some facilities about the security out of the box, so
a user can enable security without any effort.

Maybe we could implement the implement the resolver you've mentioned? Maybe
Martin's suggestion about the SecurityBean.

I still dont fancy the *UserOnRole attributes. I just think security is a
crosscutting concern and it'd be good to seperate it from the components.

Cagatay

On 8/16/06, Mike Kienenberger <mkienenb@gmail.com> wrote:
>
> Well, those are good points, but your concerns are with the
> limitations of the default EL rather than a need for a component.
>
> You can work around these limitations using the
> hashmap-as-function-parameters trick, or by using a more advanced EL
> (like the Facelets EL which supports user-defined functions).
>
> #{securityBean.isManager or securityBean.isAdmin}
>
> could become
>
> #{securityBean.ifAnyGranted['manager'] or securityBean.ifAnyGranted
> ['admin']}"
> or
> #{ifGranted(securityBean, 'manager') or ifGranted(securityBean, 'admin')}"
>
> You could even add an extra property-resolver so that these are
> resolved by an extension of EL.
>
> #{security:granted:manager or security:granted:admin}"
>
> I think trying to use a component to solve these problems is too
> limiting.   The place to deal with this is at the EL level.
>
> > what if there are other conditions that effect the rendered property of
> the panel
> > #{securityBean.isManager or securityBean.isAdmin or pageBean.isLoggedIn}
>
> That's going to be true no matter what you do.   If you feel like
> these need to be separated, then separate them out:
>
> <h:panelGroup rendered="#{pageBean.isLoggedIn}">
>     <h:panelGroup rendered="#{securityBean.isManager or
> securityBean.isAdmin}">
>
>
> On 8/16/06, Cagatay Civici <cagatay.civici@gmail.com> wrote:
> > Hi Mike,
> >
> >
> > > <h:panelGroup rendered="#{securityBean.isManager or
> securityBean.isAdmin
> > }">
> > >
> > >    //components to be secured goes here
> > > </h:panelGroup >
> > >
> >
> > Yes that would do the same job but my point is the user must create the
> > securityBean class to accomplish this.
> >
> > Also securityBean changes when a new role is added. Imagining the
> possible
> > amount of roles, the maintanence of the bean might cause problems when
> > things get more complex.
> >
> > My other concern is what if there are other conditions that effect the
> > rendered property of the panel. Then that should also be added to the
> > security concern like;
> >
> > #{securityBean.isManager or securityBean.isAdmin or pageBean.isLoggedIn}
> >
> > Anyway, I'm just thinking loud :)
> >
> > Cagatay
> >
> >
> > On 8/16/06, Mike Kienenberger <mkienenb@gmail.com> wrote:
> > > What's wrong with using this?
> > >
> > > <h:panelGroup rendered="#{securityBean.isManager or
> > securityBean.isAdmin}">
> > >     //components to be secured goes here
> > > </h:panelGroup >
> > >
> > > Seems a lot more flexible.
> > >
> > > On 8/16/06, Cagatay Civici < cagatay.civici@gmail.com> wrote:
> > > > Hi,
> > > >
> > > > What do you guys think about a security component like this;
> > > >
> > > > <s:secure ifAnyGranted="manager, admin">
> > > >     //components to be secured goes here
> > > > </s:secure>
> > > >
> > > > Also have attributes like ifNotGranted, ifAnyGranted disable and
> etc.
> > > >
> > > > Do you think this should be useful?
> > > >
> > > > Regards,
> > > >
> > > > Cagatay
> > > >
> > >
> >
> >
>

Mime
View raw message