-1 for @Result ok for other proposals
Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2012/12/15 Arne Limburg <[email protected]>: > I am also not happy with that name. > > So we have to decide about two annotations > 1. The method-level annotation of the authorizer method: > A. @Secures(BEFORE_INVOCATION) and @Secures(AFTER_INVOCATION) > B. @Secures and @SecuresResult > C. @Secures for both (pre- and post method-invocation authorization, > distinguishing by the existence of the parameter-level annotation) > 2. The parameter-level annotation of the injected result (something like a > qualifier for the result of the business-method invocation) > A. @Result > B. @SecuredResult > C. Other proposals? > > And we should consider both together, i.e. The word "Result" in the > method-level annotation AND the parameter-level annotation looks ugly. > > Cheers, > Arne > > Am 14.12.12 18:15 schrieb "Gerhard Petracek" unter > <[email protected]>: > >>-1 for @Result (as a name), because the name is too generic. >> >>regards, >>gerhard >> >> >> >>2012/12/14 Arne Limburg <[email protected]> >> >>> Hi all, >>> >>> >>> I have done the coding and we just need to agree on the names of the >>> annotations. >>> Looking at the gist I have no strong opinion on one of the solutions. >>> However I like the @Secures(AFTER_INVOCATION) a little more because of >>>to >>> things: >>> First it is symmetric to @Secures(BEFORE_INVOCATION) and second the >>>other >>> solution has the word "Result" twice in the declaration: once in the >>> method annotation and once in the parameter annotation. >>> >>> Cheers, >>> Arne >>> >>> Am 13.12.12 21:09 schrieb "Arne Limburg" unter >>> <[email protected]>: >>> >>> >Hi Mark, >>> > >>> >I have coded a gist to lookup an address from an entityManager (see >>>[1]) >>> >using the groups suggested by Rudy: >>> > >>> >group1 (in my case users with role "guest") -> no access at all >>> >group2 (in my case the owner of the address) -> has access but only to >>>a >>> >limited set of result types (access to his addresses) >>> >group3 (in my case users with role "admin") -> has access and can see >>>all >>> >result >>> > >>> >I have coded the authorizer twice once using @Secures(AFTER_INVOCATION) >>> >and once using @SecuresResult. >>> >I think it is obvious that we need just one interceptor (for the custom >>> >security annotation @Read) >>> >and it should be obvious, too, that it makes no sense to annotate one >>>of >>> >the authorizer methods with both @Secures and @SecuresResult >>> > >>> >Hope that helps, >>> >Arne >>> > >>> >[1] https://gist.github.com/4279323 >>> > >>> >Am 13.12.12 19:27 schrieb "Mark Struberg" unter <[email protected]>: >>> > >>> > >>> >>Could be helpful if we gather some samples in a gist? >>> >> >>> >>It seems that I have a different understanding about it's usage than >>>Arne >>> >>(which is much more into it). Arnes argument sounded well funded, but >>> >>this excesses my knowledge right now. >>> >> >>> >>It basically boils down to >>> >> >>> >>1. does it make sense to have both annotations on the same method? >>> >>2. will the stuff get handled by the same interceptor? (well, we will >>> >>anyway do the @Dependent InterceptorStrategy trick for it I guess, so >>>no >>> >>real problem) >>> >> >>> >> >>> >>LieGrue, >>> >>strub >>> >> >>> >> >>> >> >>> >>----- Original Message ----- >>> >>> From: Jason Porter <[email protected]> >>> >>> To: "[email protected]" >>> >>><[email protected]>; Mark Struberg >>><[email protected] >>> > >>> >>> Cc: >>> >>> Sent: Thursday, December 13, 2012 6:32 PM >>> >>> Subject: Re: [DISCUSS] DELTASPIKE-298 support >>>post-method-authorization >>> >>> >>> >>> +1 to Mark's names >>> >>> >>> >>> >>> >>> On Thu, Dec 13, 2012 at 4:13 AM, Mark Struberg <[email protected]> >>> >>>wrote: >>> >>> >>> >>>> >>> >>>> >>> >>>> 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 >>> >>>> >>>>>>>>> > >>> >>>> >>>>>>>>> > >>> >>>> >>>>>>>>> >>> >>>> >>>>>>> >>> >>>> >>>>> >>> >>>> >>> >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Jason Porter >>> >>> http://lightguard-jp.blogspot.com >>> >>> http://twitter.com/lightguardjp >>> >>> >>> >>> Software Engineer >>> >>> Open Source Advocate >>> >>> >>> >>> PGP key id: 926CCFF5 >>> >>> PGP key available at: keyserver.net, pgp.mit.edu >>> >>> >>> > >>> >>> >
