oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <pids...@apache.org>
Subject Re: APIs
Date Wed, 16 Jun 2010 08:34:24 GMT
On 16/06/2010 08:42, Simone Tripodi wrote:
> Hola,
> 
>>>
>>> if ("oauth_signature".equals(parameter)) {
>>>     // do something
>>> } else if ("oauth_version".equals(parameter)) {
>>>     // do something
>>> } else ...
>>
>> I don't see the need for that anywhere?
> 
> My fault, bad example :P Immagine our Map<String, Object> 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.  I just don't see the need to annotate fields, which you have
>> 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.


If we know that some parameters ("oauth_xxxxx"; either in headers, body
or query string in v1.0) are required, they can be specified as fields.

Under this condition, why do we need to then annotate those fields?
It's surely overkill to use reflection to access them, when we can just
use a getter method directly.


What we're talking about here is pretty detailed, low level stuff.

Somehow we've got to get down to that level - I think I can see a way to
do that by modifying the stuff I wrote to interact with the stuff Simo
wrote.

But I wonder, does the signature API need to be exposed in the API spec
or could it be entirely internal to the implementation?



p


> All the best,
> Simo
> 
> [1] http://svn.apache.org/viewvc/incubator/amber/trunk/signature-api/src/main/java/org/apache/amber/signature/signers/AbstractMethodAlgorithm.java?view=markup
> [2] http://java.sun.com/javase/6/docs/api/java/util/Collections.html#binarySearch(java.util.List,
> T)
> 
>> p
>>
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>>
>>>
>>>
>>> On Tue, Jun 15, 2010 at 9:46 PM, Pid <pidster@apache.org> 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.  I think that perhaps a Map might be more simple though -
>>>> 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 <pidster@apache.org> 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<S extends SigningKey,
V
>>>>>>> extends VerifyingKey>
>>>>>>>
>>>>>>> where defined the the method to calculate the signature (throws
>>>>>>> SignatureException if any error occurs):
>>>>>>>
>>>>>>>     String calculate(S signingKey,
>>>>>>>             String secretCredential,
>>>>>>>             Service service,
>>>>>>>             RequestMessage message,
>>>>>>>             Parameter... parameters) throws SignatureException;
>>>>>>>
>>>>>>> and the one to verify the signature:
>>>>>>>
>>>>>>> boolean verify(String signature,
>>>>>>>             V verifyingKey,
>>>>>>>             String secretCredential,
>>>>>>>             Service service,
>>>>>>>             RequestMessage message,
>>>>>>>             Parameter... parameters) throws SignatureException;
>>>>>>>
>>>>>>> An abstract implementation, AbstractSignatureMethodAlgorithm,
contains
>>>>>>> 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<HmacSha1Key, HmacSha1Key> {
>>>>>>> ...
>>>>>>> }
>>>>>>>
>>>>>>> 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:
>>>>>>>     HEAD,
>>>>>>>     POST,
>>>>>>>     PUT,
>>>>>>>     GET,
>>>>>>>     DELETE,
>>>>>>>     OPTIONS,
>>>>>>>     TRACE,
>>>>>>>     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 annotation,
>>>>>>> to mark if the field:
>>>>>>> - is optional (false by default)
>>>>>>> - has to be included in the parameter list to calculate the signature
>>>>>>> (true by default)
>>>>>>> - moreover contains the oauth parameter name
>>>>>>>
>>>>>>> a sample can be found on the signature field:
>>>>>>>
>>>>>>> @OAuthParameter(
>>>>>>>             name = "oauth_signature",
>>>>>>>             includeInSignature = false
>>>>>>>     )
>>>>>>>     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
welcome!!!!
>>>>>>
>>>>>> I hope you'll forgive me for saying so, but I think it's quite
>>>>>> complicated.  Annotations are nice, but seem like overkill for this
>>>>>> 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 <simoneg@apache.org>
wrote:
>>>>>>>> Hi Simo,
>>>>>>>> obviously current SVN *is* the starting point.
>>>>>>>>
>>>>>>>> Let's see how to continue on that line, if there are other
proposals, 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 current API
>>>>>>>> with their app.
>>>>>>>>
>>>>>>>> Simone
>>>>>>>>
>>>>>>>> 2010/6/15 Simone Tripodi <simone.tripodi@gmail.com>
>>>>>>>>
>>>>>>>>> Hi Simo,
>>>>>>>>> currently in the current svn Amber repo there is the
signature (with
>>>>>>>>> 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 could
>>>>>>>>> be extracted from there.
>>>>>>>>>
>>>>>>>>> Feel free to ask questions if some parts are not clear.
>>>>>>>>> All the best,
>>>>>>>>> Simo
>>>>>>>>>
>>>>>>>>> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 15, 2010 at 2:21 PM, Simone Gianni <simoneg@apache.org>
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 worse than
>>>>>>>>>> another. It mostly depends on use cases.
>>>>>>>>>>
>>>>>>>>>> Amber will (as many other systems) interact with
:
>>>>>>>>>> - external applications/frameworks, using Amber to
integrate oauth
>>>>>>>>>> - internal extensions, providing for example different
token storages 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 one API,
>>>>>>>>> for
>>>>>>>>>> example a low level one and high level Fa├žade. Since
our goal is to unify
>>>>>>>>>> different (often existing) pieces and ease the path
of adoption on
>>>>>>>>> projects
>>>>>>>>>> that were planning to integrate OAuth, we'll need
a bit of flexibility.
>>>>>>>>>>
>>>>>>>>>> Cast your code sample ideas :) People in projects
that already use their
>>>>>>>>> own
>>>>>>>>>> implementation of OAuth can easily post real code.
>>>>>>>>>>
>>>>>>>>>> Simone
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>



Mime
View raw message