+1 Br, Ove
On Dec 16, 2012, at 7:10 PM, Jason Porter wrote: > Ah, got it thanks. Not being a security person I'm sure how often this comes > up, but it does seem useful in some situations. > > +1 for 4. > > Sent from my iPhone > > On Dec 16, 2012, at 7:31, Arne Limburg <[email protected]> wrote: > >> Hi Jason, >> >> >> You seem to be not the only one on the list that is not so deep into the >> details, so here a short explanation of the usage of the current @Secures >> and the changes, that will be done by DELTASPIKE-298: >> >> The idea of the current @Secures stuff is, that the user can create a >> CUSTOM annotation to secure business method invocations (the @Read >> annotation in the gist example). The only thing he needs to do is, to >> annotate that annotation with @SecurityBindingType. >> >> Deltaspike security then automatically calls an authorizer method to >> check, if the current user is authorized to call methods with that >> annotation. This authorizer methods are methods that are annotated with >> @Secures and the CUSTOM annotation. Parameters of that method are injected >> via normal CDI injection (i.e. You could inject a Principal or, if you >> produce it somewhere, the current request). >> >> This call to the authorizer method is done BEFORE the call to the business >> method. However there are situations where you want to check the result of >> the business method invocation and base your access decision on it (see >> examples on this thread). And this is, where DELTASPIKE-298 comes into >> play: the idea is, that one of the parameters of the authorizer method can >> be declared to be the result of the business method invocation. To mark >> one parameter of the AUTHORIZER method as such, we need an annotation to >> distinguish that parameter from a normal injection point. And that is the >> first annotation, we need to agree upon. Proposals are >> 1. @Result >> 2. @SecuredResult >> 3. @SecuredOnReturn >> 4. @SecuredReturn >> >> So the authorizer method would read like: >> >> 1. public boolean isAllowedToRead(@Result Address a... >> 2. public boolean isAllowedToRead(@SecuredResult Address a... >> 3. public boolean isAllowedToRead(@SecuredOnReturn Address a... >> 4. public boolean isAllowedToRead(@SecuredReturn Address a... >> >> I agree with gerhard that 1. is to generic and I personally think that 3. >> reads not so smooth >> >> I am fine with 2. and 4. but like 4. more because of the occurrence of the >> java keyword "return" >> >> WDYT? >> >> Cheers, >> Arne >> >> >> >> Am 15.12.12 23:17 schrieb "Jason Porter" unter <[email protected]>: >> >>> Personally I don't see when a case would arise when you know after a >>> method has been invoked that the user shouldn't be using it versus >>> knowing that before. >>> >>> As for the void, maybe its my misunderstanding of this concept we're >>> talking about :) >>> >>> Sent from my iPhone >>> >>> On Dec 15, 2012, at 15:13, Arne Limburg <[email protected]> >>> wrote: >>> >>>> Hi Jason, >>>> >>>> >>>> We are checking the return value and if the user is not allowed to see >>>> it, >>>> we reject it, so basically we ARE securing the return valueĊ >>>> >>>> About your objections for the void method: Do you have any use case >>>> where >>>> a security check AFTER a call to a void method makes sense? >>>> >>>> Am 15.12.12 23:10 schrieb "Jason Porter" unter >>>> <[email protected]>: >>>> >>>>> +1 SecuresOnReturn or maybe SecuresAfterReturn >>>>> >>>>> -1 SecuresReturn. Just looking at it makes it seem like they're going >>>>> be >>>>> securing the returned value which is certainly not the case. Also it >>>>> doesn't makes if you put it on a void method >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Dec 15, 2012, at 14:29, Gerhard Petracek >>>>> <[email protected]> >>>>> wrote: >>>>> >>>>>> +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 >>
