Some time ago I started work on an OAuth test provider/consumer. It will be much better to use than the current oauth sandbox.
Should finish work somewhere in the coming weeks, though am a bit occupied with my new born son :-) It is based on the oauth-php code at http://code.google.com/p/oauth-php/ Greetings, Marc Worrell On 11 jan 2009, at 06:01, Krishna Sankar (ksankar) wrote: > > Yep, client, server a set of vectors and a wiki document would be a > good > start. Would be happy to pitch-in. > Cheers > <k/> > > |-----Original Message----- > |From: [email protected] [mailto:[email protected]] On > Behalf > |Of Hans Granqvist > |Sent: Saturday, January 10, 2009 9:29 AM > |To: [email protected] > |Subject: [oauth] Re: Standardizing the OAuth Client Libraries > | > | > |Very useful blog post, thanks! > | > | > |For me, an OAuth RI has three parts: > | > |1. Client code (consumer mainly). > | > |2. Server code (service provider) or a testable live service. > | > |3. A set of test vectors so that 1. and 2. know a certain > |set of input yield a specific set of output. (This is not > |trivial when randomness is part of a protocol, btw.) > | > | > |No need for extreme formality to get started. For developers, > |any "official best-effort" reference implementation OAuth endpoints > |running somewhere would be invaluable. > | > |http://oauth.net seems a natural place, but it could be anywhere > |as long as everyone agrees. > | > |Any takers? > | > |Hans > | > | > | > |On Jan 8, 2009, at 8:24 PM, Eran Hammer-Lahav wrote: > | > |> > |> BTW, ignoring the fact that it part of it (RSA-SHA1) only works on > |> Windows, I consider my signature blog post [1] a reference > |> implementation of OAuth written in JS. > |> > |> EHL > |> > |> [1] http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html > |> > |> > |> > |> On Jan 8, 5:44 pm, John Kristian <[email protected]> wrote: > |>> By 'programming interface' I mean an interface between software > |>> modules, like between an OAuth library and software that calls it. > |>> By > |>> 'protocol interface' I mean the bytes transmitted over the network > |>> between the consumer and service provider. Think of a layering > |>> diagram, in which an OAuth library has a programming interface to > |>> higher-level things, and down toward the bottom is a protocol > |>> interface. > |>> > |>> Take percent encoding for example. Neglecting to percent encode > |>> leads > |>> to a protocol violation, but when you investigate the root cause > you > |>> might find that the OAuth library provides a correct encoding > |>> algorithm but the application neglected to call it. (Users of the > |>> Java library have done this.) I would say that's a programming > |>> problem: it was caused by erroneous interaction between the > |>> application and the library. The protocol violation is merely a > |>> consequence. > |>> > |>> Making the signature base string available for debugging is a fine > |>> idea. > |>> > |>> On Jan 8, 11:35 am, Jesse Clark <[email protected]> wrote: > |>> > |>>> John, could you expand on what you mean by 'programming > interface' > |>>> vs. > |>>> 'protocol interface' problems? > |>> > |>>> At ma.gnolia, we spent a pretty decent amount of time helping > people > |>>> debug rejected signatures that were usually resulting from > |>>> differences > |>>> in both how the implementor of the client library composed the > |>>> Signature Base String and differences in how the various URL > |>>> libraries > |>>> from different platforms handle encoding. I would call these > |>>> 'protocol' issues not software design issues. > |>> > |>>> However, while trying to debug problems with conflicting > signatures, > |>>> it was often necessary to ask the client user to try to find the > SBS > |>>> for a given set of inputs which was not always easy. So, software > |>>> design guidelines suggesting a debug mode that would log the SBS > |>>> data > |>>> somewhere might be a good idea too. > |>> > |>> > |> > > | > | > | > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
