A business method could have both, but an authorizer method may not have both.
Am 13.12.12 12:28 schrieb "Rudy De Busscher" unter <[email protected]>: >I agree with Mark, > >*A method could also have both* > >*@Secures* (does the user has authorization to execute this method) >*and @SecuresResul*t (does he has the right to see this kind of result) > >This is the case where you have 3 (or more) kind of users >group1 -> no access at all >group2 -> has access but only to a limited set of result types >group3 -> has access and can see all result types > >There is no point in allowing the user to execute the method and >afterwards >see that he doesn't has access (group 1 ) > >regards >Rudy > >On 13 December 2012 12:23, Arne Limburg ><[email protected]>wrote: > >> 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 >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> >> >>>>>>>> >> >>>>>> >> >>>> >> >> >> >> >> >> >> >> >> >>
