Return-Path: X-Original-To: apmail-incubator-deltaspike-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-deltaspike-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9AD26E165 for ; Sat, 15 Dec 2012 22:18:15 +0000 (UTC) Received: (qmail 83887 invoked by uid 500); 15 Dec 2012 22:18:15 -0000 Delivered-To: apmail-incubator-deltaspike-dev-archive@incubator.apache.org Received: (qmail 83854 invoked by uid 500); 15 Dec 2012 22:18:15 -0000 Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: deltaspike-dev@incubator.apache.org Delivered-To: mailing list deltaspike-dev@incubator.apache.org Received: (qmail 83846 invoked by uid 99); 15 Dec 2012 22:18:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Dec 2012 22:18:15 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS,T_FILL_THIS_FORM_SHORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lightguard.jp@gmail.com designates 209.85.210.47 as permitted sender) Received: from [209.85.210.47] (HELO mail-da0-f47.google.com) (209.85.210.47) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Dec 2012 22:18:11 +0000 Received: by mail-da0-f47.google.com with SMTP id s35so1863363dak.6 for ; Sat, 15 Dec 2012 14:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=6clgnlIW8IukJmpUY5Bc+TqirAeyQbxPpMEZGWgZFGo=; b=YwJGQoadz2V7DcE997ds8xkXBth4H3h1EefMt0k/eaj3Z7puGjBPBMygsMucU+bgKM xsxdXGZ1eZ7v/Ff22Z3eCjuG+HYHxZuSb5rqeOIfhJfdZsn7MotJ5Uw/CJ2Nt29diwxQ xKkC9Lw9u7p2FMSlgncygpbhxlvX1unH4035Q6L/i6MYaKmxVbypxsbrmM1HTdYU2hQl 94F1g0GN2pxlLe2YilqWfE/7y5hYWb+bIhYD6+V5sc47w6Q7tY5Sdbqd/cZIQuOZWsnd F7f42DJ/UcqDvnmpzZEqap82cSWRvqwuUH4c/SCZ1/quq+Sk7UUeimUe/eWLa0LQclPE Le3Q== Received: by 10.68.223.35 with SMTP id qr3mr28661339pbc.27.1355609870776; Sat, 15 Dec 2012 14:17:50 -0800 (PST) Received: from [192.168.1.207] (63-248-81-177.static.sdyl010.digis.net. [63.248.81.177]) by mx.google.com with ESMTPS id x2sm5641293paw.8.2012.12.15.14.17.49 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 14:17:50 -0800 (PST) References: <97621E8BA4D496449BC4D1AB06E0FB7004C046@K99F-PEXC01.openknowledge.de> Mime-Version: 1.0 (1.0) In-Reply-To: <97621E8BA4D496449BC4D1AB06E0FB7004C046@K99F-PEXC01.openknowledge.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Cc: "deltaspike-dev@incubator.apache.org" X-Mailer: iPhone Mail (10A523) From: Jason Porter Subject: Re: [DISCUSS] DELTASPIKE-298 support post-method-authorization Date: Sat, 15 Dec 2012 15:17:45 -0700 To: "deltaspike-dev@incubator.apache.org" X-Virus-Checked: Checked by ClamAV on apache.org Personally I don't see when a case would arise when you know after a method h= as been invoked that the user shouldn't be using it versus knowing that befo= re.=20 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 wrot= e: > Hi Jason, >=20 >=20 > 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=C5=A0 >=20 > 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? >=20 > Am 15.12.12 23:10 schrieb "Jason Porter" unter : >=20 >> +1 SecuresOnReturn or maybe SecuresAfterReturn >>=20 >> -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 >>=20 >> Sent from my iPhone >>=20 >> On Dec 15, 2012, at 14:29, Gerhard Petracek >> wrote: >>=20 >>> +1 for @SecuredOnReturn or @SecuredResult as an additional annotation >>> (-> >>> no api changes for @Secures). >>>=20 >>> regards, >>> gerhard >>>=20 >>>=20 >>>=20 >>> 2012/12/15 Arne Limburg >>>=20 >>>> 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: >>>>=20 >>>> public boolean isAllowedToRead(@SecuredReturn Address a... >>>>=20 >>>>=20 >>>>=20 >>>> So +1 for @SecuredReturn from me >>>>=20 >>>>=20 >>>> [1] https://gist.github.com/4279323 >>>>=20 >>>>=20 >>>>=20 >>>> Am 15.12.12 21:59 schrieb "Romain Manni-Bucau" unter >>>> : >>>>=20 >>>>> and the secure one too so it is not ambigous +1 for this one >>>>>=20 >>>>> Romain Manni-Bucau >>>>> Twitter: @rmannibucau >>>>> Blog: http://rmannibucau.wordpress.com/ >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>> Github: https://github.com/rmannibucau >>>>>=20 >>>>>=20 >>>>>=20 >>>>> 2012/12/15 Arne Limburg : >>>>>> 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 >>>>>>=20 >>>>>> What do the others think? >>>>>>=20 >>>>>>=20 >>>>>> Am 15.12.12 21:51 schrieb "Gerhard Petracek" unter >>>>>> : >>>>>>=20 >>>>>>> we could add @SecuredOnReturn to the list. >>>>>>>=20 >>>>>>> regards, >>>>>>> gerhard >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> 2012/12/15 Arne Limburg >>>>>>>=20 >>>>>>>> I am also not happy with that name. >>>>>>>>=20 >>>>>>>> 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? >>>>>>>>=20 >>>>>>>> And we should consider both together, i.e. The word "Result" in the= >>>>>>>> method-level annotation AND the parameter-level annotation looks >>>>>>>> ugly. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Arne >>>>>>>>=20 >>>>>>>> Am 14.12.12 18:15 schrieb "Gerhard Petracek" unter >>>>>>>> : >>>>>>>>=20 >>>>>>>>> -1 for @Result (as a name), because the name is too generic. >>>>>>>>>=20 >>>>>>>>> regards, >>>>>>>>> gerhard >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 2012/12/14 Arne Limburg >>>>>>>>>=20 >>>>>>>>>> Hi all, >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>> Arne >>>>>>>>>>=20 >>>>>>>>>> Am 13.12.12 21:09 schrieb "Arne Limburg" unter >>>>>>>>>> : >>>>>>>>>>=20 >>>>>>>>>>> Hi Mark, >>>>>>>>>>>=20 >>>>>>>>>>> I have coded a gist to lookup an address from an entityManager >>>>>>>> (see >>>>>>>>>> [1]) >>>>>>>>>>> using the groups suggested by Rudy: >>>>>>>>>>>=20 >>>>>>>>>>> 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 >>>>>>>>>>>=20 >>>>>>>>>>> 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 >>>>>>>>>>>=20 >>>>>>>>>>> Hope that helps, >>>>>>>>>>> Arne >>>>>>>>>>>=20 >>>>>>>>>>> [1] https://gist.github.com/4279323 >>>>>>>>>>>=20 >>>>>>>>>>> Am 13.12.12 19:27 schrieb "Mark Struberg" unter >>>>>>>> : >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> Could be helpful if we gather some samples in a gist? >>>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> It basically boils down to >>>>>>>>>>>>=20 >>>>>>>>>>>> 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) >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> LieGrue, >>>>>>>>>>>> strub >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> From: Jason Porter >>>>>>>>>>>>> To: "deltaspike-dev@incubator.apache.org" >>>>>>>>>>>>> ; Mark Struberg >>>>>>>>>> >>>>>>>>>>=20 >>>>>>>>>>>>> Cc: >>>>>>>>>>>>> Sent: Thursday, December 13, 2012 6:32 PM >>>>>>>>>>>>> Subject: Re: [DISCUSS] DELTASPIKE-298 support >>>>>>>>>> post-method-authorization >>>>>>>>>>>>>=20 >>>>>>>>>>>>> +1 to Mark's names >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Thu, Dec 13, 2012 at 4:13 AM, Mark Struberg >>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> what about @Secures and @SecuresResult? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> These are 2 different inteceptors, right? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A method could also have both >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> @Secures and >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> @SecuresResult >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>>> strub >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> ________________________________ >>>>>>>>>>>>>>> From: Arne Limburg >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> OK, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> so I would go with your first suggestion, Romain: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> @Secures(BEFORE_INVOCATION) and @Secures(AFTER_INVOCATION) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> That would leave the readability of the authorizer method >>>>>>>> and >>>>>>>>>>>>>>> BEFORE_INVOCATION could be the default, so that it could >>>>>>>> left >>>>>>>>>> blank. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 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) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Wdyt? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Am 13.12.12 12:03 schrieb "Romain Manni-Bucau" unter >>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> if you add the "post" management @Secures will be >>>>>>>>>>>>> ambiguous (even if >>>>>>>>>>>>>>>> naturally i understand pre is implicit) so i'd just switch >>>>>>>> it >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> if the API is explicit enough to not need doc it is better >>>>>>>> ;) >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>> Twitter: @rmannibucau >>>>>>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/ >>>>>>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>>>>>>>>>>>>> Github: https://github.com/rmannibucau >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> 2012/12/13 Arne Limburg : >>>>>>>>>>>>>>>>> Btw. are we talking about another name for @Secures or >>>>>>>> for >>>>>>>>>>>>> @Result? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> 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... >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Am 13.12.12 11:55 schrieb "Romain Manni-Bucau" unter >>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> so i'd go for @PreSecures and @PostSecures, just >>>>>>>>>>>>> explicit >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> but i wouldn't something not symmetrical >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>>> Twitter: @rmannibucau >>>>>>>>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/ >>>>>>>>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>>>>>>>>>>>>>>> Github: https://github.com/rmannibucau >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> 2012/12/13 Arne Limburg >>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>> @Secures sounds cool at a first glance, but may it be >>>>>>>>>>>>> confusing for >>>>>>>>>>>>>>>>>>> users? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> 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: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> @Copy >>>>>>>>>>>>>>>>>>> public MyObject copy(@Source MyObject source) { >>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> public class MyCopyAuthorizer { >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> @Secures @Copy >>>>>>>>>>>>>>>>>>> public boolean isCopyAllowed(@Source MyObject >>>>>>>>>>>>> source, >>>>>>>>>>>>>>>>>>> @SecuredReturnValue MyObject target) { >>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> where @Copy is a @SecurityBindingType and @Source is a >>>>>>>>>>>>>>>>>>> @SecurityParameterBinding >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>> Arne >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Am 13.12.12 11:45 schrieb "Romain >>>>>>>>>>>>> Manni-Bucau" unter >>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Why @Secures is not fine? >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> if the rule is "on parameter" it is a >>>>>>>>>>>>> post it can be enough. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Another solution is @Secure(hook =3D POST) with a >>>>>>>>>>>>> default to PRE >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>>>>> Twitter: @rmannibucau >>>>>>>>>>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/ >>>>>>>>>>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>>>>>>>>>>>>>>>>> Github: https://github.com/rmannibucau >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> 2012/12/13 Arne Limburg >>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>> Feel free to make a suggestion. >>>>>>>>>>>>>>>>>>>>> What about >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> @SecuredResult >>>>>>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>>>>>> @SecuredReturnValue >>>>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Am 13.12.12 10:50 schrieb "Gerhard >>>>>>>>>>>>> Petracek" unter >>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> +1, but imo we need a better name for it. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> regards, >>>>>>>>>>>>>>>>>>>>>> gerhard >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 2012/12/13 Rudy De Busscher >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> All, >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> I had once also such a requirement >>>>>>>>>>>>> (post-method authorization) >>>>>>>>>>>>>>>>>>>>>>> where >>>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>> could be very handy. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> So >>>>>>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>> Rudy >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> On 13 December 2012 09:26, Arne >>>>>>>>>>>>> Limburg >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> Hi Jean-Louis, >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> 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: >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> public class MyObjectRepository { >>>>>>>>>>>>>>>>>>>>>>>> @Create >>>>>>>>>>>>>>>>>>>>>>>> public MyObject create() { >>>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> public class MyAuthorizer { >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> @Secures @Create >>>>>>>>>>>>>>>>>>>>>>>> public boolean >>>>>>>>>>>>> canCreate(@Result MyObject object) { >>>>>>>>>>>>>>>>>>>>>>>> // security check here >>>>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> 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... >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>>>>>> Arne >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> Am 13.12.12 09:20 schrieb >>>>>>>>>>>>> "Jean-Louis MONTEIRO" unter < >>>>>>>>>>>>>>>>>>>>>>> jeanouii@gmail.com >>>>>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> Hi Arne, >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> Jean-Louis >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> 2012/12/13 Mark Struberg >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>>>>>>>>>>>>>> Arne Limburg schrieb am >>>>>>>>>>>>> Mi., 12. Dez 2012 23:38 PST: >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>>>>>>>>> Arne >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>> https://issues.apache.org/jira/browse/DELTASPIKE-298 >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>> Jean-Louis >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Jason Porter >>>>>>>>>>>>> http://lightguard-jp.blogspot.com >>>>>>>>>>>>> http://twitter.com/lightguardjp >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Software Engineer >>>>>>>>>>>>> Open Source Advocate >>>>>>>>>>>>>=20 >>>>>>>>>>>>> PGP key id: 926CCFF5 >>>>>>>>>>>>> PGP key available at: keyserver.net, pgp.mit.edu >=20