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