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