deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [DISCUSS] DELTASPIKE-298 support post-method-authorization
Date Thu, 13 Dec 2012 11:26:56 GMT
so i prefer BEFORE_.. and AFTER_...

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 <arne.limburg@openknowledge.de>:
> I would have put it into the same interceptor, but that is an
> implementation detail.
>
>
> And it makes no sense to make the same authorizer method a pre- and
> post-authorizer method:
> Either you don't need the result, than you can decide to do the check
> before or after the invocation, but it makes no sense to do the same check
> before AND after the invocation
> or you need the result then you are stuck with AFTER_INVOCATION
>
> This is an argument to use one annotation for both cases (and
> differentiate via an annotation parameter)
>
> Cheers,
> Arne
>
> Am 13.12.12 12:13 schrieb "Mark Struberg" unter <struberg@yahoo.de>:
>
>>
>>
>>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 <arne.limburg@openknowledge.de>
>>>To: "deltaspike-dev@incubator.apache.org"
>>><deltaspike-dev@incubator.apache.org>
>>>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
>>><rmannibucau@gmail.com>:
>>>
>>>>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 <arne.limburg@openknowledge.de>:
>>>>> 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
>>>>> <rmannibucau@gmail.com>:
>>>>>
>>>>>>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 <arne.limburg@openknowledge.de>:
>>>>>>> @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
>>>>>>> <rmannibucau@gmail.com>:
>>>>>>>
>>>>>>>>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 <arne.limburg@openknowledge.de>:
>>>>>>>>> Feel free to make a suggestion.
>>>>>>>>> What about
>>>>>>>>>
>>>>>>>>> @SecuredResult
>>>>>>>>> or
>>>>>>>>> @SecuredReturnValue
>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>> Am 13.12.12 10:50 schrieb "Gerhard Petracek" unter
>>>>>>>>> <gerhard.petracek@gmail.com>:
>>>>>>>>>
>>>>>>>>>>+1, but imo we need a better name for it.
>>>>>>>>>>
>>>>>>>>>>regards,
>>>>>>>>>>gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>2012/12/13 Rudy De Busscher <rdebusscher@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>><arne.limburg@openknowledge.de
>>>>>>>>>>> >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 <
>>>>>>>>>>> jeanouii@gmail.com
>>>>>>>>>>> > >:
>>>>>>>>>>> >
>>>>>>>>>>> > >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 <struberg@yahoo.de>
>>>>>>>>>>> > >
>>>>>>>>>>> > >>
>>>>>>>>>>> > >>
>>>>>>>>>>> > >> +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
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>>
>>>
>

Mime
View raw message