Re: [Snowy] OAuth in Snowy

[Sandy Armstrong <sanfordarmstrong gmail com>]

On Thu, Jun 11, 2009 at 7:11 AM, Stuart
Langridge<stuart langridge canonical com> wrote:
> Sandy Armstrong wrote:
>> But I realized we are going to have some issues:
>>
>> 1. The request_token, authorize, and access_token base URLs need to be
>> done the same way on all implementing servers, *or* we need to have
>> them specified in the root resource we recently added to the API (this
>> means one additional request before starting the OAuth process).
>
> I personally think that they should be in the same place on each server;
> rooturl/oauth/authenticate etc. If someone has a massive, massive need
> to do them elsewhere, they can always add HTTP redirects from the
> "Tomboy-required" URLs to whatever they want.

Okay, I'm fine with this for now.  So the URLs are:

base/oauth/request_token
base/oauth/authenticate
base/oauth/access_token

Right?

>> 2. The OAuth consumer key and consumer secret need to be identical in
>> each server implementation, or specified by the user, or acquired
>> through some other hackery.  This could be a big problem, I think.
>> Perhaps the solution is to generate dozens of reserved pairs just for
>> this API, and work together to assign them to different client apps?
>> I think it would be really handy of Tomboy, Tomdroid, Conboy, etcs,
>> all had different consumer keys and secrets (so if one of them has a
>> bug that DDoS's servers, we can selectively throttle).  I guess that
>> could also be done with user agent, but I think that's not the "right"
>> way?
>
> I specified consumer key and consumer secret for Tomboy as "tomboy" for
> each. Since it's open source the key and secret are relatively
> irrelevant, and are not secret (this is a thing about OAuth generally,
> not specific to our implementation of it); they're like a user-agent
> string (as you note), so they're useful as an optional "flag" (so you
> can say "throttle 'tomboy' because it's got a bug in it, or similar).

Okay, that makes a lot of sense (assuming it doesn't somehow hurt
cryptographic integrity of the rest of the signature stuff).  Still,
all server implementers need to collaborate on those.

Thanks,
Sandy