deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [DISCUSS] DELTASPIKE-298 support post-method-authorization
Date Sat, 15 Dec 2012 22:07:50 GMT
that's why i didn't mention backward compatibility at all.
(imo changing the api of @Secures for this feature is just not needed...)

regards,
gerhard



2012/12/15 Arne Limburg <arne.limburg@openknowledge.de>

> Hence I supposted to use BEFORE_INVOCATION as default value such that
> existing applications would continue to work as before. So it would be a
> backward-compatible api change.
>
>
> But I am also happy with using just @Secures and detect the existence of a
> @SecuredReturn parameter to determine, if pre-method authorization should
> take place or post-method invocation.
>
> Am 15.12.12 22:44 schrieb "Gerhard Petracek" unter
> <gerhard.petracek@gmail.com>:
>
> >hi arne,
> >
> >adding a value to @Secures (e.g. AFTER_INVOCATION) would be such a change.
> >
> >regards,
> >gerhard
> >
> >
> >
> >2012/12/15 Arne Limburg <arne.limburg@openknowledge.de>
> >
> >> 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
> >> <gerhard.petracek@gmail.com>:
> >>
> >> >+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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message