On 07/07/2010 10:46, Pid wrote:
Wrong list me thinks.
Mark
> On 07/07/2010 09:39, Simone Tripodi wrote:
>> Hola Pid
>>
>> On Tue, Jul 6, 2010 at 10:38 PM, Pid <p...@pidster.com> wrote:
>>>
>>> I'm working on a prototype integrating the signature-api with the config
>>> stuff & the spec api. Couple of things:
>>>
>>> #1
>>>
>>
>> no problems/objections, feel free to commit it ;)
>>
>>> #2
>>>
>>> I'm trying to understand whether it would be possible for the
>>> SignatureMethodAlgorithm interface to be refactored to just use the Key
>>> interface, or (SigningKey, VerifyingKey) directly.
>>>
>>
>> Unfortunately, nope. That would be easier if we could take in
>> consideration only algorithms such PLAINTEXT and HMAC_SHA1, where the
>> same key is used to both sign/verify the signature, but with RSA
>> things are quite more complicated.
>> Using RSA involves users have to use a private key to sign, and a
>> public certificate to validate. Sounds reasonable - at least to me -
>> that keys have to be typed, since, potentially, trying to verify an
>> HMAC signature with an RSA public key is wrong.
>
> I thought as much. Hmm.
>
>>> I assume it's defined like this so an implementation can require it's
>>> own key classes to be used?
>>>
>>>
>>> The problem is that I don't think we will be able to use the
>>> ServiceLoader mechanism to discover and use signature implementations.
>>>
>>
>> I think your idea is still valid, adding just minor modifications,
>> something similar that I already did in the past[1]:
>> - with the service loader mechanism, you discover all SignatureMethod
>> implementations and optionally store them in a Registry;
>> - when a client try to generate/verify a signature, by the key it
>> could access to the registry and take the relative algorithm.
>
> Yep. That's the idea.
>
>
>> Quite clean and easy, thoughts?
>
> In principal, yes, in practice there's some problems that I can't quite
> work out. Whether we use ServiceLoader or an equivalent duplicate, the
> problem is as as follows...
>
> Very simply:
>
> Map<String, SignatureMethod> registry = ...;
> ClassLoader loader = ...;
>
> ServiceLoader<SignatureMethod> services =
> ServiceLoader.load(SignatureMethod.class, loader);
>
> for (SignatureMethod sm : services) {
> registry.put(sm.getAlgorithm(), sm);
> }
>
>
> Without doing massive quantities of reflection - and I don't know if
> even that will do it - the SignatureMethod can only be loaded if it is
> not enhanced with generic types.
>
> Even if it was possible to store it efficiently, I can't see a way to
> then use it.
>
> String algorithm = oAuthRequest.getAlgorithm();
> SignatureMethod method = registry.get(algorithm);
>
> If method was extracted:
>
> SignatureMethod<K,V> method = registry.get(algorithm);
>
> We then need *another* mechanism which helps us create the proper,
> matching keys K and V so we can create a concrete object.
>
> K key = createTheKey(oAuthRequest.getSigBase());
> // how do we do this?
>
> String signature = calculate(key, oAuthRequest);
>
>
> I'm a bit stumped. How were you handling this?
>
>
> p
>
>
>
>
>
>> Simo
>>
>> [1]
>> http://code.google.com/p/asmx-oauth/source/browse/trunk/core/commons/src/main/java/com/asemantics/oauth/core/signers/RequestSignerRegistry.java
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
