deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: [DISCUSS] DELTASPIKE-298 support post-method-authorization
Date Sat, 15 Dec 2012 22:17:45 GMT
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 <arne.limburg@openknowledge.de> 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 <lightguard.jp@gmail.com>:
> 
>> +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 <gerhard.petracek@gmail.com>
>> wrote:
>> 
>>> +1 for @SecuredOnReturn or @SecuredResult as an additional annotation
>>> (->
>>> no api changes for @Secures).
>>> 
>>> regards,
>>> gerhard
>>> 
>>> 
>>> 
>>> 2012/12/15 Arne Limburg <arne.limburg@openknowledge.de>
>>> 
>>>> 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
>>>> <rmannibucau@gmail.com>:
>>>> 
>>>>> 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 <arne.limburg@openknowledge.de>:
>>>>>> 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
>>>>>> <gerhard.petracek@gmail.com>:
>>>>>> 
>>>>>>> we could add @SecuredOnReturn to the list.
>>>>>>> 
>>>>>>> regards,
>>>>>>> gerhard
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 2012/12/15 Arne Limburg <arne.limburg@openknowledge.de>
>>>>>>> 
>>>>>>>> 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
>>>>>>>> <gerhard.petracek@gmail.com>:
>>>>>>>> 
>>>>>>>>> -1 for @Result (as a name), because the name is too generic.
>>>>>>>>> 
>>>>>>>>> regards,
>>>>>>>>> gerhard
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2012/12/14 Arne Limburg <arne.limburg@openknowledge.de>
>>>>>>>>> 
>>>>>>>>>> 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
>>>>>>>>>> <arne.limburg@openknowledge.de>:
>>>>>>>>>> 
>>>>>>>>>>> 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
>>>>>>>> <struberg@yahoo.de>:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> 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 <lightguard.jp@gmail.com>
>>>>>>>>>>>>> To: "deltaspike-dev@incubator.apache.org"
>>>>>>>>>>>>> <deltaspike-dev@incubator.apache.org>;
Mark Struberg
>>>>>>>>>> <struberg@yahoo.de
>>>>>>>>>>> 
>>>>>>>>>>>>> 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
>>>>>>>> <struberg@yahoo.de>
>>>>>>>>>>>>> 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 <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
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 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
> 

Mime
View raw message