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 >>
