Hi Gerhard,

I am a little confused. What do you mean by "no api change for @Secures"?
Are you talking about the method level annotation or the parameter
annotation that is needed as a "qualifier" for the result of the business
method?

Am 15.12.12 22:29 schrieb "Gerhard Petracek" unter
<[email protected]>:

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

Reply via email to