Re: [Snowy] OAuth in Snowy
- From: Sandy Armstrong <sanfordarmstrong gmail com>
- To: Stuart Langridge <stuart langridge canonical com>
- Cc: snowy-list gnome org
- Subject: Re: [Snowy] OAuth in Snowy
- Date: Thu, 11 Jun 2009 07:27:09 -0700
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:
>> 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"
> 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.
] [Thread Prev