Return-Path: Delivered-To: apmail-incubator-amber-dev-archive@minotaur.apache.org Received: (qmail 85823 invoked from network); 16 Jun 2010 07:42:36 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 16 Jun 2010 07:42:36 -0000 Received: (qmail 19736 invoked by uid 500); 16 Jun 2010 07:42:36 -0000 Delivered-To: apmail-incubator-amber-dev-archive@incubator.apache.org Received: (qmail 19707 invoked by uid 500); 16 Jun 2010 07:42:35 -0000 Mailing-List: contact amber-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: amber-dev@incubator.apache.org Delivered-To: mailing list amber-dev@incubator.apache.org Received: (qmail 19699 invoked by uid 99); 16 Jun 2010 07:42:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jun 2010 07:42:34 +0000 X-ASF-Spam-Status: No, hits=-0.3 required=10.0 tests=AWL,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of simone.tripodi@gmail.com designates 74.125.78.150 as permitted sender) Received: from [74.125.78.150] (HELO ey-out-1920.google.com) (74.125.78.150) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jun 2010 07:42:27 +0000 Received: by ey-out-1920.google.com with SMTP id 26so819034eyw.4 for ; Wed, 16 Jun 2010 00:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=e6zpoQuYEakQxdJLaS0NhGXeiO3R1ZVfR34gMhHNsSM=; b=PQQsgvvAJy076vFq04NR72yeLRGCazxcjrc/7Ay1ythQ7FISIaBGcE9dZm7fPbr9g4 SWkh1GMz5aEYteJltwJ3qY4zrd04VGpPjjsKSYBxMfXve0YhgNzI0Zq2a7KtoZ+aLpya OxFrEIbONbaG9lIBv/C0Fzv33HtJZpHitcXHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=wzQ/u7uJSqGBQoVifV+xqYwymEo1YuBoiwBJIGDVPffbXXNvkdxvzMW5PAPp5vmjlE QCPLbH6p+Hb7GLuQSHql+saXyBVSzxLoUhR7PKLM+KNC2lH2c0TziXWQuAeIFRdmlEZp v8hMYL26lQ02kPxc5tu4Z9X6IK4DCwRFkZtZo= MIME-Version: 1.0 Received: by 10.213.12.196 with SMTP id y4mr1698533eby.12.1276674125931; Wed, 16 Jun 2010 00:42:05 -0700 (PDT) Received: by 10.213.16.137 with HTTP; Wed, 16 Jun 2010 00:42:05 -0700 (PDT) In-Reply-To: <4C17E29F.8010407@pidster.com> References: <4C17BE5B.4000000@apache.org> <4C17D895.8030101@apache.org> <4C17E29F.8010407@pidster.com> Date: Wed, 16 Jun 2010 09:42:05 +0200 Message-ID: Subject: Re: APIs From: Simone Tripodi To: amber-dev@incubator.apache.org, pid@pidster.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hola, >> >> if ("oauth_signature".equals(parameter)) { >> =C2=A0 =C2=A0 // do something >> } else if ("oauth_version".equals(parameter)) { >> =C2=A0 =C2=A0 // do something >> } else ... > > I don't see the need for that anywhere? My fault, bad example :P Immagine our Map parameters: * if we get parameter on by one, for every parameter we get we've to check is not null (redundant and not so nice to see). * if we iterate over map entry set, we're forced to check the parameter by name as above; That are the reason why at the end I switched to annotations, to maintain the code as clean as possible. >> maybe everybody agrees that this is not so nice to have in our code :P > > Me either. > >> Generally speaking, I'd continue prefer maintain POJOs instead the >> algorithm, since POJOs are just types declaration and don't contain >> any logic. > >> More thoughts? > > I agree. =C2=A0I just don't see the need to annotate fields, which you ha= ve > to list, then sort alphabetically (for correct concatenation), before > reflectively extracting their values. In the current code base in the svn[1] is shown that's possible building a sorted list while adding parameter, thanks to the Collections#binarySearch() algorithm; for every added element we have a complexity of O(log(n)) where n in our case is small. > Maybe I misunderstood; you were only referring to the known OAuth > parameters rather than the possible additional parameters that a > Consumer might need, that have to be supplied to the Provider during auth= ? > Annotations are valid only for known OAuth parameter; when a consumer needs to add additional parameters, these will be added using the same algorithm (without any check, of course) that continues working with the same efficiency. All the best, Simo [1] http://svn.apache.org/viewvc/incubator/amber/trunk/signature-api/src/ma= in/java/org/apache/amber/signature/signers/AbstractMethodAlgorithm.java?vie= w=3Dmarkup [2] http://java.sun.com/javase/6/docs/api/java/util/Collections.html#binary= Search(java.util.List, T) > p > >> Simo >> >> http://people.apache.org/~simonetripodi/ >> >> >> >> On Tue, Jun 15, 2010 at 9:46 PM, Pid wrote: >>> On 15/06/2010 20:07, Simone Tripodi wrote: >>>> Hi Pid, >>>> that's curious and funny at the same time, that's exactly what I've >>>> always avoided to do :) And don't worry, even if with totally >>>> different vision, we're here to work together for the same purpose, >>>> that's why we partecipate in a community, otherwise everybody could >>>> work alone, no? :P >>>> >>>> In the case of the Message, the reason why I thought so is that >>>> annotations contain not only the name parameter name, but also some >>>> logic hints that avoid us hard-coding logic in the client algorithm, >>>> like exclude parameters during the signature, the optional fields and >>>> so on. >>>> It helps to maintains the code more flexible - if new parameters have >>>> to be added, just extend the POJO and add new annotation, logic has >>>> not to be changed - and consequently more maintainable. >>> >>> I understand. =C2=A0I think that perhaps a Map might be more simple tho= ugh - >>> you wouldn't need to recompile to handle new parameters? >>> >>> >>> p >>> >>>> http://people.apache.org/~simonetripodi/ >>>> >>>> >>>> >>>> On Tue, Jun 15, 2010 at 7:54 PM, Pid wrote: >>>>> On 15/06/2010 16:14, Simone Tripodi wrote: >>>>>> Hi Simo, >>>>>> absolutely right, let's find a better way to describe how I started >>>>>> designing the signature APIs... >>>>>> >>>>>> First of all: use cases show us that there are symmetric algorithms >>>>>> (PLAINTEXT, HMAC_SHA) and asymmetric algorithms (RSA_SHA1), so the >>>>>> design should be able to be adaptable for both cases. I thought that= a >>>>>> symmetric algorithm is a special case of an asymmetric algorithm, so >>>>>> let's consider having a SigningKey and a VerifyingKey interfaces, in >>>>>> the case of a symmetric algorithm, the key implementation have to >>>>>> implement both interfaces. >>>>>> >>>>>> So, let's define the SignatureMethodAlgorithm - I hope the name is >>>>>> semful!!! That's the interface definition >>>>>> >>>>>> public interface SignatureMethodAlgorithm>>>>> extends VerifyingKey> >>>>>> >>>>>> where defined the the method to calculate the signature (throws >>>>>> SignatureException if any error occurs): >>>>>> >>>>>> =C2=A0 =C2=A0 String calculate(S signingKey, >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 String secretCredential, >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Service service, >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RequestMessage message, >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Parameter... parameters) t= hrows SignatureException; >>>>>> >>>>>> and the one to verify the signature: >>>>>> >>>>>> boolean verify(String signature, >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 V verifyingKey, >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 String secretCredential, >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Service service, >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RequestMessage message, >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Parameter... parameters) t= hrows SignatureException; >>>>>> >>>>>> An abstract implementation, AbstractSignatureMethodAlgorithm, contai= ns >>>>>> common signature calculation stuff, like the base string creation. >>>>>> Any SignatureMethodAlgorithm implementation is annotated by a >>>>>> @SignatureMethod annotation to mark the oauth algorithm identifier, >>>>>> ie: >>>>>> >>>>>> @SignatureMethod("HMAC-SHA1") >>>>>> public final class HmacSha1MethodAlgorithm extends >>>>>> AbstractMethodAlgorithm { >>>>>> ... >>>>>> } >>>>>> >>>>>> Let's now make clear what hell Service, RequestMessage and Parameter= are :) >>>>>> >>>>>> >>>>>> Service is the pair (URL, HttpMethod) that describes the service has >>>>>> to be invoked. HttpMethod is an enumeration of all admitted http >>>>>> method: >>>>>> =C2=A0 =C2=A0 HEAD, >>>>>> =C2=A0 =C2=A0 POST, >>>>>> =C2=A0 =C2=A0 PUT, >>>>>> =C2=A0 =C2=A0 GET, >>>>>> =C2=A0 =C2=A0 DELETE, >>>>>> =C2=A0 =C2=A0 OPTIONS, >>>>>> =C2=A0 =C2=A0 TRACE, >>>>>> =C2=A0 =C2=A0 CONNECT >>>>>> >>>>>> >>>>>> RequestMessage is a POJO that contains the OAuth parameters like >>>>>> version, nonce, timestamp, ... it is extended by the >>>>>> TokenRequestMessage that differs from the previous one because >>>>>> contains the token field. >>>>>> Every RequestMessage field is annotated by @OAuthParameter annotatio= n, >>>>>> to mark if the field: >>>>>> - is optional (false by default) >>>>>> - has to be included in the parameter list to calculate the signatur= e >>>>>> (true by default) >>>>>> - moreover contains the oauth parameter name >>>>>> >>>>>> a sample can be found on the signature field: >>>>>> >>>>>> @OAuthParameter( >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 name =3D "oauth_signature"= , >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 includeInSignature =3D fal= se >>>>>> =C2=A0 =C2=A0 ) >>>>>> =C2=A0 =C2=A0 private String signature; >>>>>> >>>>>> That's all in therms of design, there are few little tricks on the >>>>>> implementation side (java introspection rocks) but IMHO is small and >>>>>> intuitive. >>>>>> >>>>>> What do you think about it? Thoughts? Any feedback is more than welc= ome!!!! >>>>> >>>>> I hope you'll forgive me for saying so, but I think it's quite >>>>> complicated. =C2=A0Annotations are nice, but seem like overkill for t= his >>>>> use-case. >>>>> >>>>> If the POJO contains all of the necessary items as named fields, why = not >>>>> just concatenate and encode them in the correct order? >>>>> >>>>> >>>>> p >>>>> >>>>> >>>>> (Sorry Simo!) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> All the best, have a nice reading :P >>>>>> Simo >>>>>> >>>>>> http://people.apache.org/~simonetripodi/ >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 15, 2010 at 4:17 PM, Simone Gianni = wrote: >>>>>>> Hi Simo, >>>>>>> obviously current SVN *is* the starting point. >>>>>>> >>>>>>> Let's see how to continue on that line, if there are other proposal= s, if >>>>>>> some of our other existing code bases approach in a different way, = or if >>>>>>> someone foresees some other kind of problems in integrating the cur= rent API >>>>>>> with their app. >>>>>>> >>>>>>> Simone >>>>>>> >>>>>>> 2010/6/15 Simone Tripodi >>>>>>> >>>>>>>> Hi Simo, >>>>>>>> currently in the current svn Amber repo there is the signature (wi= th >>>>>>>> implementation) and part of consumer APIs I wrote time ago for the >>>>>>>> Lab. >>>>>>>> They are still valid IMHO and part of my proposal, parts of code c= ould >>>>>>>> be extracted from there. >>>>>>>> >>>>>>>> Feel free to ask questions if some parts are not clear. >>>>>>>> All the best, >>>>>>>> Simo >>>>>>>> >>>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jun 15, 2010 at 2:21 PM, Simone Gianni wrote: >>>>>>>>> Hi all, >>>>>>>>> so, one part of our roadmap are APIs. >>>>>>>>> >>>>>>>>> Each of us has his own idea of how an API should be, in general, = and many >>>>>>>> of >>>>>>>>> us already have an idea (or even code) on how an OAuth API should= be :) >>>>>>>>> >>>>>>>>> There is no "absolute way" to determine if an API is better or wo= rse than >>>>>>>>> another. It mostly depends on use cases. >>>>>>>>> >>>>>>>>> Amber will (as many other systems) interact with : >>>>>>>>> - external applications/frameworks, using Amber to integrate oaut= h >>>>>>>>> - internal extensions, providing for example different token stor= ages or >>>>>>>>> interation different backends >>>>>>>>> - modules of Amber itself >>>>>>>>> >>>>>>>>> I think it would be better to focus on the first API now : which = use >>>>>>>> cases >>>>>>>>> do we plan? How do you imagine the code of a web framework using = Amber >>>>>>>> look >>>>>>>>> like? >>>>>>>>> >>>>>>>>> If there are very different cases there is space for more than on= e API, >>>>>>>> for >>>>>>>>> example a low level one and high level Fa=C3=A7ade. Since our goa= l is to unify >>>>>>>>> different (often existing) pieces and ease the path of adoption o= n >>>>>>>> projects >>>>>>>>> that were planning to integrate OAuth, we'll need a bit of flexib= ility. >>>>>>>>> >>>>>>>>> Cast your code sample ideas :) People in projects that already us= e their >>>>>>>> own >>>>>>>>> implementation of OAuth can easily post real code. >>>>>>>>> >>>>>>>>> Simone >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >