OK, So if noone else has objections, I'll go with approach one from the gist (the one described in ReadingAuthorizer0): @Secures at the method and @SecuredReturn at the parameter.
Cheers, Arne Am 15.12.12 23:07 schrieb "Gerhard Petracek" unter <[email protected]>: >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 >> >> >> >>>> >> >>> >> >> >> >>>> >> > >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >>>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
