+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 > >>>> >> >>> > >>>> >> > > >>>> >> > >>>> >> > >>>> > >>>> > >> > >
