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