that's why i didn't mention backward compatibility at all. (imo changing the api of @Secures for this feature is just not needed...)
regards, gerhard 2012/12/15 Arne Limburg <[email protected]> > Hence I supposted to use BEFORE_INVOCATION as default value such that > existing applications would continue to work as before. So it would be a > backward-compatible api change. > > > But I am also happy with using just @Secures and detect the existence of a > @SecuredReturn parameter to determine, if pre-method authorization should > take place or post-method invocation. > > Am 15.12.12 22:44 schrieb "Gerhard Petracek" unter > <[email protected]>: > > >hi arne, > > > >adding a value to @Secures (e.g. AFTER_INVOCATION) would be such a change. > > > >regards, > >gerhard > > > > > > > >2012/12/15 Arne Limburg <[email protected]> > > > >> Hi Gerhard, > >> > >> > >> I am a little confused. What do you mean by "no api change for > >>@Secures"? > >> Are you talking about the method level annotation or the parameter > >> annotation that is needed as a "qualifier" for the result of the > >>business > >> method? > >> > >> Am 15.12.12 22:29 schrieb "Gerhard Petracek" unter > >> <[email protected]>: > >> > >> >+1 for @SecuredOnReturn or @SecuredResult as an additional annotation > >>(-> > >> >no api changes for @Secures). > >> > > >> >regards, > >> >gerhard > >> > > >> > > >> > > >> >2012/12/15 Arne Limburg <[email protected]> > >> > > >> >> I've updated the gist [1] (see ReadingAuthorizer0) to see how it > >>works > >> >>out. > >> >> If we leave out the "on", then it would even read better. You could > >>read > >> >> the method call like a sentence: > >> >> > >> >> public boolean isAllowedToRead(@SecuredReturn Address a... > >> >> > >> >> > >> >> > >> >> So +1 for @SecuredReturn from me > >> >> > >> >> > >> >> [1] https://gist.github.com/4279323 > >> >> > >> >> > >> >> > >> >> Am 15.12.12 21:59 schrieb "Romain Manni-Bucau" unter > >> >> <[email protected]>: > >> >> > >> >> >and the secure one too so it is not ambigous +1 for this one > >> >> > > >> >> >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]>: > >> >> >> You mean to the second list? > >> >> >> I like that, because it contains the java keyword "return" > >> >> >> With this I would feel comfortable with 1.C > >> >> >> > >> >> >> What do the others think? > >> >> >> > >> >> >> > >> >> >> Am 15.12.12 21:51 schrieb "Gerhard Petracek" unter > >> >> >> <[email protected]>: > >> >> >> > >> >> >>>we could add @SecuredOnReturn to the list. > >> >> >>> > >> >> >>>regards, > >> >> >>>gerhard > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>>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 > >> >> >>>> >> >>> > >> >> >>>> >> > > >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> > >> >> >>>> > >> >> >> > >> >> > >> >> > >> > >> > >
