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 >
