-1 for @Result (as a name), because the name is too generic.

regards,
gerhard



2012/12/14 Arne Limburg <[email protected]>

> Hi all,
>
>
> I have done the coding and we just need to agree on the names of the
> annotations.
> Looking at the gist I have no strong opinion on one of the solutions.
> However I like the @Secures(AFTER_INVOCATION) a little more because of to
> things:
> First it is symmetric to @Secures(BEFORE_INVOCATION) and second the other
> solution has the word "Result" twice in the declaration: once in the
> method annotation and once in the parameter annotation.
>
> Cheers,
> Arne
>
> Am 13.12.12 21:09 schrieb "Arne Limburg" unter
> <[email protected]>:
>
> >Hi Mark,
> >
> >I have coded a gist to lookup an address from an entityManager (see [1])
> >using the groups suggested by Rudy:
> >
> >group1 (in my case users with role "guest")  -> no access at all
> >group2 (in my case the owner of the address) -> has access but only to a
> >limited set of result types (access to his addresses)
> >group3 (in my case users with role "admin")  -> has access and can see all
> >result
> >
> >I have coded the authorizer twice once using @Secures(AFTER_INVOCATION)
> >and once using @SecuresResult.
> >I think it is obvious that we need just one interceptor (for the custom
> >security annotation @Read)
> >and it should be obvious, too, that it makes no sense to annotate one of
> >the authorizer methods with both @Secures and @SecuresResult
> >
> >Hope that helps,
> >Arne
> >
> >[1] https://gist.github.com/4279323
> >
> >Am 13.12.12 19:27 schrieb "Mark Struberg" unter <[email protected]>:
> >
> >
> >>Could be helpful if we gather some samples in a gist?
> >>
> >>It seems that I have a different understanding about it's usage than Arne
> >>(which is much more into it). Arnes argument sounded well funded, but
> >>this excesses my knowledge right now.
> >>
> >>It basically boils down to
> >>
> >>1. does it make sense to have both annotations on the same method?
> >>2. will the stuff get handled by the same interceptor? (well, we will
> >>anyway do the @Dependent InterceptorStrategy trick for it I guess, so no
> >>real problem)
> >>
> >>
> >>LieGrue,
> >>strub
> >>
> >>
> >>
> >>----- Original Message -----
> >>> From: Jason Porter <[email protected]>
> >>> To: "[email protected]"
> >>><[email protected]>; Mark Struberg <[email protected]
> >
> >>> Cc:
> >>> Sent: Thursday, December 13, 2012 6:32 PM
> >>> Subject: Re: [DISCUSS] DELTASPIKE-298 support post-method-authorization
> >>>
> >>> +1 to Mark's names
> >>>
> >>>
> >>> On Thu, Dec 13, 2012 at 4:13 AM, Mark Struberg <[email protected]>
> >>>wrote:
> >>>
> >>>>
> >>>>
> >>>>  what about @Secures and @SecuresResult?
> >>>>
> >>>>  These are 2 different inteceptors, right?
> >>>>
> >>>>  A method could also have both
> >>>>
> >>>>  @Secures and
> >>>>
> >>>>  @SecuresResult
> >>>>
> >>>>
> >>>>  LieGrue,
> >>>>  strub
> >>>>
> >>>>  >________________________________
> >>>>  > From: Arne Limburg <[email protected]>
> >>>>  >To: "[email protected]" <
> >>>>  [email protected]>
> >>>>  >Sent: Thursday, December 13, 2012 12:11 PM
> >>>>  >Subject: Re: [DISCUSS] DELTASPIKE-298 support
> >>>>post-method-authorization
> >>>>  >
> >>>>  >OK,
> >>>>  >
> >>>>  >so I would go with your first suggestion, Romain:
> >>>>  >
> >>>>  >@Secures(BEFORE_INVOCATION) and @Secures(AFTER_INVOCATION)
> >>>>  >
> >>>>  >That would leave the readability of the authorizer method and
> >>>>  >BEFORE_INVOCATION could be the default, so that it could left blank.
> >>>>  >
> >>>>  >
> >>>>  >Of course the extension detects at deployment time the problem that
> >>>>a
> >>>>  >authorizer method exists with @Secures(BEFORE_INVOCATION) and a
> >>> parameter
> >>>>  >annotated with @Result and suggests to use
> >>>>@Secures(AFTER_INVOCATION)
> >>>>  >
> >>>>  >Wdyt?
> >>>>  >
> >>>>  >Am 13.12.12 12:03 schrieb "Romain Manni-Bucau" unter
> >>>>  ><[email protected]>:
> >>>>  >
> >>>>  >>if you add the "post" management @Secures will be
> >>> ambiguous (even if
> >>>>  >>naturally i understand pre is implicit) so i'd just switch it
> >>>>  >>
> >>>>  >>if the API is explicit enough to not need doc it is better ;)
> >>>>  >>
> >>>>  >>Romain Manni-Bucau
> >>>>  >>Twitter: @rmannibucau
> >>>>  >>Blog: http://rmannibucau.wordpress.com/
> >>>>  >>LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>  >>Github: https://github.com/rmannibucau
> >>>>  >>
> >>>>  >>
> >>>>  >>
> >>>>  >>2012/12/13 Arne Limburg <[email protected]>:
> >>>>  >>> Btw. are we talking about another name for @Secures or for
> >>> @Result?
> >>>>  >>>
> >>>>  >>> Thinking about @Secures it should not be too confusing
> >>> (talking with
> >>>>  >>> myself here ;-) ), since the developer knows, if he needs the
> >>> result
> >>>>  for
> >>>>  >>> evaluation or not. So either he adds @Result and will know
> >>> that the
> >>>>  >>>method
> >>>>  >>> needs to be invoked before the authorization. Or he
> >>> doesn't need the
> >>>>  >>> result, then the intuitive thing is, that the authorization
> >>> takes place
> >>>>  >>> before the business method invocation...
> >>>>  >>>
> >>>>  >>> Am 13.12.12 11:55 schrieb "Romain Manni-Bucau" unter
> >>>>  >>> <[email protected]>:
> >>>>  >>>
> >>>>  >>>>so i'd go for @PreSecures and @PostSecures, just
> >>> explicit
> >>>>  >>>>
> >>>>  >>>>but i wouldn't something not symmetrical
> >>>>  >>>>
> >>>>  >>>>Romain Manni-Bucau
> >>>>  >>>>Twitter: @rmannibucau
> >>>>  >>>>Blog: http://rmannibucau.wordpress.com/
> >>>>  >>>>LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>  >>>>Github: https://github.com/rmannibucau
> >>>>  >>>>
> >>>>  >>>>
> >>>>  >>>>
> >>>>  >>>>2012/12/13 Arne Limburg
> >>> <[email protected]>:
> >>>>  >>>>> @Secures sounds cool at a first glance, but may it be
> >>> confusing for
> >>>>  >>>>>users?
> >>>>  >>>>>
> >>>>  >>>>>
> >>>>  >>>>> And also we should support a mixture of
> >>> @SecurityParameterBindings
> >>>>  and
> >>>>  >>>>> result, so the annotation should somehow indicate that
> >>> the parameter
> >>>>  >>>>>is
> >>>>  >>>>> the return value of the method invocation.
> >>>>  >>>>> Consider the following example:
> >>>>  >>>>>
> >>>>  >>>>> @Copy
> >>>>  >>>>> public MyObject copy(@Source MyObject source) {
> >>>>  >>>>>   ...
> >>>>  >>>>> }
> >>>>  >>>>>
> >>>>  >>>>> public class MyCopyAuthorizer {
> >>>>  >>>>>
> >>>>  >>>>>   @Secures @Copy
> >>>>  >>>>>   public boolean isCopyAllowed(@Source MyObject
> >>> source,
> >>>>  >>>>> @SecuredReturnValue MyObject target) {
> >>>>  >>>>>     ...
> >>>>  >>>>>   }
> >>>>  >>>>> }
> >>>>  >>>>>
> >>>>  >>>>> where @Copy is a @SecurityBindingType and @Source is a
> >>>>  >>>>> @SecurityParameterBinding
> >>>>  >>>>>
> >>>>  >>>>> Cheers,
> >>>>  >>>>> Arne
> >>>>  >>>>>
> >>>>  >>>>> Am 13.12.12 11:45 schrieb "Romain
> >>> Manni-Bucau" unter
> >>>>  >>>>> <[email protected]>:
> >>>>  >>>>>
> >>>>  >>>>>>Why @Secures is not fine?
> >>>>  >>>>>>
> >>>>  >>>>>>if the rule is "on parameter" it is a
> >>> post it can be enough.
> >>>>  >>>>>>
> >>>>  >>>>>>Another solution is @Secure(hook = POST) with a
> >>> default to PRE
> >>>>  >>>>>>
> >>>>  >>>>>>Romain Manni-Bucau
> >>>>  >>>>>>Twitter: @rmannibucau
> >>>>  >>>>>>Blog: http://rmannibucau.wordpress.com/
> >>>>  >>>>>>LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>  >>>>>>Github: https://github.com/rmannibucau
> >>>>  >>>>>>
> >>>>  >>>>>>
> >>>>  >>>>>>
> >>>>  >>>>>>2012/12/13 Arne Limburg
> >>> <[email protected]>:
> >>>>  >>>>>>> Feel free to make a suggestion.
> >>>>  >>>>>>> What about
> >>>>  >>>>>>>
> >>>>  >>>>>>> @SecuredResult
> >>>>  >>>>>>> or
> >>>>  >>>>>>> @SecuredReturnValue
> >>>>  >>>>>>> ?
> >>>>  >>>>>>>
> >>>>  >>>>>>> Am 13.12.12 10:50 schrieb "Gerhard
> >>> Petracek" unter
> >>>>  >>>>>>> <[email protected]>:
> >>>>  >>>>>>>
> >>>>  >>>>>>>>+1, but imo we need a better name for it.
> >>>>  >>>>>>>>
> >>>>  >>>>>>>>regards,
> >>>>  >>>>>>>>gerhard
> >>>>  >>>>>>>>
> >>>>  >>>>>>>>
> >>>>  >>>>>>>>
> >>>>  >>>>>>>>2012/12/13 Rudy De Busscher
> >>> <[email protected]>
> >>>>  >>>>>>>>
> >>>>  >>>>>>>>> All,
> >>>>  >>>>>>>>>
> >>>>  >>>>>>>>> I had once also such a requirement
> >>> (post-method authorization)
> >>>>  >>>>>>>>>where
> >>>>  >>>>>>>>>this
> >>>>  >>>>>>>>> could be very handy.
> >>>>  >>>>>>>>>
> >>>>  >>>>>>>>> We kept information about persons
> >>> (name, age, address, medical
> >>>>  >>>>>>>>>info,
> >>>>  >>>>>>>>>...)
> >>>>  >>>>>>>>> but there where some categories. One
> >>> kind of category was linked
> >>>>  >>>>>>>>>to
> >>>>  >>>>>>>>>the
> >>>>  >>>>>>>>> Royals and you needed a special role
> >>> before you could read the
> >>>>  >>>>>>>>>information.
> >>>>  >>>>>>>>>
> >>>>  >>>>>>>>> So we where only able to determine if
> >>> the user was allowed to
> >>>>  read
> >>>>  >>>>>>>>>the
> >>>>  >>>>>>>>> person information after we had read
> >>> it frmo the database and
> >>>>  >>>>>>>>>matched
> >>>>  >>>>>>>>>the
> >>>>  >>>>>>>>> category.
> >>>>  >>>>>>>>>
> >>>>  >>>>>>>>> So
> >>>>  >>>>>>>>> +1
> >>>>  >>>>>>>>>
> >>>>  >>>>>>>>> Regards
> >>>>  >>>>>>>>> Rudy
> >>>>  >>>>>>>>>
> >>>>  >>>>>>>>>
> >>>>  >>>>>>>>> On 13 December 2012 09:26, Arne
> >>> Limburg
> >>>>  >>>>>>>>><[email protected]
> >>>>  >>>>>>>>> >wrote:
> >>>>  >>>>>>>>>
> >>>>  >>>>>>>>> > Hi Jean-Louis,
> >>>>  >>>>>>>>> >
> >>>>  >>>>>>>>> > A simple use case is a method
> >>> that creates an object, stores it
> >>>>  >>>>>>>>>to
> >>>>  >>>>>>>>>the
> >>>>  >>>>>>>>> > database and returns it.
> >>>>  >>>>>>>>> > You may want to check the object
> >>> to decide if the user is
> >>>>  >>>>>>>>>allowed
> >>>>  >>>>>>>>>to
> >>>>  >>>>>>>>> > create it. With my proposal it is
> >>> as easy as:
> >>>>  >>>>>>>>> >
> >>>>  >>>>>>>>> > public class MyObjectRepository {
> >>>>  >>>>>>>>> >   @Create
> >>>>  >>>>>>>>> >   public MyObject create() {
> >>>>  >>>>>>>>> >      ...
> >>>>  >>>>>>>>> >   }
> >>>>  >>>>>>>>> > }
> >>>>  >>>>>>>>> >
> >>>>  >>>>>>>>> > public class MyAuthorizer {
> >>>>  >>>>>>>>> >
> >>>>  >>>>>>>>> >   @Secures @Create
> >>>>  >>>>>>>>> >   public boolean
> >>> canCreate(@Result MyObject object) {
> >>>>  >>>>>>>>> >     // security check here
> >>>>  >>>>>>>>> >   }
> >>>>  >>>>>>>>> > }
> >>>>  >>>>>>>>> >
> >>>>  >>>>>>>>> >
> >>>>  >>>>>>>>> > Hope that makes it clear. And
> >>> note that the check may depend on
> >>>>  >>>>>>>>>the
> >>>>  >>>>>>>>>state
> >>>>  >>>>>>>>> > of the object, i.e. the user is
> >>> just allowed to create the
> >>>>  >>>>>>>>>object,
> >>>>  >>>>>>>>>if
> >>>>  >>>>>>>>>he
> >>>>  >>>>>>>>> > is the owner...
> >>>>  >>>>>>>>> >
> >>>>  >>>>>>>>> > Cheers,
> >>>>  >>>>>>>>> > Arne
> >>>>  >>>>>>>>> >
> >>>>  >>>>>>>>> > Am 13.12.12 09:20 schrieb
> >>> "Jean-Louis MONTEIRO" unter <
> >>>>  >>>>>>>>> [email protected]
> >>>>  >>>>>>>>> > >:
> >>>>  >>>>>>>>> >
> >>>>  >>>>>>>>> > >Hi Arne,
> >>>>  >>>>>>>>> > >
> >>>>  >>>>>>>>> > >Just read the JIRA but could
> >>> not find a relevant use case for
> >>>>  >>>>>>>>>that.
> >>>>  >>>>>>>>> > >But if you proposed it, I
> >>> probably missed something so if you
> >>>>  >>>>>>>>>could
> >>>>  >>>>>>>>> > >elaborate a bit more.
> >>>>  >>>>>>>>> > >
> >>>>  >>>>>>>>> > >Jean-Louis
> >>>>  >>>>>>>>> > >
> >>>>  >>>>>>>>> > >
> >>>>  >>>>>>>>> > >2012/12/13 Mark Struberg
> >>> <[email protected]>
> >>>>  >>>>>>>>> > >
> >>>>  >>>>>>>>> > >>
> >>>>  >>>>>>>>> > >>
> >>>>  >>>>>>>>> > >> +1
> >>>>  >>>>>>>>> > >>
> >>>>  >>>>>>>>> > >>
> >>>>  >>>>>>>>> > >>
> >>> ------------------------------
> >>>>  >>>>>>>>> > >> Arne Limburg schrieb am
> >>> Mi., 12. Dez 2012 23:38 PST:
> >>>>  >>>>>>>>> > >>
> >>>>  >>>>>>>>> > >> >Hi,
> >>>>  >>>>>>>>> > >> >
> >>>>  >>>>>>>>> > >> >What do you think of
> >>> supporting post-method-authorization
> >>>>  >>>>>>>>>(see
> >>>>  >>>>>>>>>[1])
> >>>>  >>>>>>>>> in
> >>>>  >>>>>>>>> > >> addition to our current
> >>> pre-method-authorization?
> >>>>  >>>>>>>>> > >> >I just started
> >>> coding it and it is not much to do.
> >>>>  >>>>>>>>> > >> >
> >>>>  >>>>>>>>> > >> >Cheers,
> >>>>  >>>>>>>>> > >> >Arne
> >>>>  >>>>>>>>> > >> >
> >>>>  >>>>>>>>> > >> >[1]
> >>> https://issues.apache.org/jira/browse/DELTASPIKE-298
> >>>>  >>>>>>>>> > >> >
> >>>>  >>>>>>>>> > >>
> >>>>  >>>>>>>>> > >>
> >>>>  >>>>>>>>> > >
> >>>>  >>>>>>>>> > >
> >>>>  >>>>>>>>> > >--
> >>>>  >>>>>>>>> > >Jean-Louis
> >>>>  >>>>>>>>> >
> >>>>  >>>>>>>>> >
> >>>>  >>>>>>>>>
> >>>>  >>>>>>>
> >>>>  >>>>>
> >>>>  >>>
> >>>>  >
> >>>>  >
> >>>>  >
> >>>>  >
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jason Porter
> >>> http://lightguard-jp.blogspot.com
> >>> http://twitter.com/lightguardjp
> >>>
> >>> Software Engineer
> >>> Open Source Advocate
> >>>
> >>> PGP key id: 926CCFF5
> >>> PGP key available at: keyserver.net, pgp.mit.edu
> >>>
> >
>
>

Reply via email to