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