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 >
