so i prefer BEFORE_.. and AFTER_... 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]>: > I would have put it into the same interceptor, but that is an > implementation detail. > > > And it makes no sense to make the same authorizer method a pre- and > post-authorizer method: > Either you don't need the result, than you can decide to do the check > before or after the invocation, but it makes no sense to do the same check > before AND after the invocation > or you need the result then you are stuck with AFTER_INVOCATION > > This is an argument to use one annotation for both cases (and > differentiate via an annotation parameter) > > Cheers, > Arne > > Am 13.12.12 12:13 schrieb "Mark Struberg" unter <[email protected]>: > >> >> >>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 >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >>> >>> >>> >
