Just take a look at https://gist.github.com/4279323 that should make it clear :-)
Am 15.12.12 23:17 schrieb "Jason Porter" unter <[email protected]>: >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 <[email protected]> >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 >><[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 >>
