incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cagatay Civici" <cagatay.civ...@gmail.com>
Subject Re: Re: Trinidad and Tomahawk
Date Wed, 16 Aug 2006 10:58:04 GMT
I've created a set of security components for JSF, mainly they are about JSF
components of Acegi Security but they still work without Acegi now.

My idea is to seperate the security concern from components and their
components and create a guard component like;

<s:secure ifAnyGranted="manager, admin">
    //components to be secured goes here
</s:secure>

Component has also other attributes like ifNotGranted, ifAllGranted, disable
and etc.

The advantage is individual components do not know anything about the
security concerns, imagine there are other conditions for the rendered and
disabled properties so the user need to && or || these conditions both with
the security condition. We've handled the JSF security with this way in my
last project and it did the job.

Regards,

Cagatay

On 8/16/06, Martin Marinschek <martin.marinschek@gmail.com> wrote:
>
> Adam's workaround for using map-parameters as function parameters is
> implemented in two MyFaces-helper classes  - named ActionMap and
> TestsMap.
>
> regards,
>
> Martin
>
> On 8/8/06, Adam Winer <awiner@gmail.com> wrote:
> > Frank,
> >
> > I think the best way to implement this is to have a Map<String, Boolean>
> > that handles this transformation for you, so you can say:
> >
> >   disabled="#{userInRole['manager']}"
> >
> > This sort of bean should be exposed out-of-the-box (would be
> > nice if it in were in the JSF standard, but easy enough to write
> > on your own).
> >
> >
> > Some problems with creating bonus properties are that you:
> >  (A) Have to remember to add them to all components
> >  (B) Have to expose multiple properties, one for everything that
> >     might be affected - rendered, readonly, disabled.
> >  (C) Aren't helped if you need to bind some other attribute (what
> >    if you wanted a different styleClass depending on the role?)
> >  (D) Aren't helped if you're not using only the absolute standard
> >    user-in-role mechanism - no, one size *does not* fit all
> >  (E) Impose performance overhead on *all* components, even
> >    those that don't need the attribute, since you have to get
> >    the property and check it no matter what
> >
> > These are, more-or-less, the same reasons why I argued fiercely
> > against adding "bundle" properties for translation and in favor
> > of using EL for that purpose - a decision I'm convinced has been
> > proven correct.
> >
> > -- Adam
> >
> >
> > On 8/8/06, Frank Nimphius <frank.nimphius@oracle.com> wrote:
> > > Adam,
> > >
> > > EL doesn't allow arguments in which case isUserInRole() checking
> > > requires the developer to create a managed bean first to then provide
> > > boolean return values. Though not reflected in the JSF spec, I think
> > > that providing out-of-the box security always is a benefit. At least
> > > this way you can ensure it is implemented the est way possible.
> However,
> > > this goes beyond implementing security on a single UI Component only
> but
> > > requires security to be enabled on the JSF engine.
> > >
> > > Just my 2 cents on it
> > >
> > > Frank
> > >
> > > Adam Winer wrote:
> > > > There has not been a decision on adding either role checking
> > > > or force ID to Trinidad.
> > > >
> > > > My personal starting position is that I'd be -1 on adding
> > > > either.  Role checking is better accomplished via setting
> > > > EL on disabled and readOnly, and force ID is unnecessary
> > > > in JSF 1.2 with h:form prependId="false" (and the
> > > > removal of requirements for using f:subview).
> > > >
> > > > -- Adam
> > > >
> > > >
> > > > On 8/7/06, Baker,Jonathan <BakerJ@oclc.org> wrote:
> > > >>
> > > >> I believe that I read somewhere that while in incubation the
> important
> > > >> attributes of tomahawk (forceid, role checking) would be added to
> the
> > > >> trinidad components.  Unfortunately I cannot remember or find where
> I
> > > >> read that statement.  I wanted to verify with the list that this is
> > > >> true.  Will trinidad and tomahawk eventually be merged into one set
> of
> > > >> components that support the skinning and things of ADF, but also
> support
> > > >> the forceid, and role checking of tomahawk.
> > > >>
> > > >> JB
> > > >>
> > > >>
> > > >>
> > > >
> > >
> > > --
> > >
> > > ________________________________
> > > Frank Nimphius
> > > Principal Product Manager
> > > Application Development Tools
> > > Oracle Corporation
> > > mail: frank.nimphius@oracle.com
> > > phone:+49 2058 782481
> > >
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message