myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: s:secure
Date Wed, 16 Aug 2006 14:28:38 GMT
Hi,

by the way - if you need to supply more than one parameter, there is
even the possibility to use a double-indexed syntax, as in:

#{securityBean['currentRegion']['manager']}

regards,

Martin

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


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Mime
View raw message