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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>>>>>>> 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 <[email protected]>
>>>>>>>>
>>>>>>>>> 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 <[email protected]>
>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
signature.asc
Description: OpenPGP digital signature
