SPs are free to require additional parameters, but they should have a good reason to do so, and they're supposed to be for auth-related data, not random SP-specific parameters. So unless each SP invents its own auth extension this should be a rare problem.
-- John Panzer / Blogger [email protected] / abstractioneer.org <http://www.abstractioneer.org/> / @jpanzer On Fri, May 8, 2009 at 11:15 AM, Richard Wallace < [email protected]> wrote: > Thanks Kevin, that worked perfectly. But... it doesn't really address > the underlying issue that it's going to be impossible for Shindig to > interoperate with every OAuth Service provider out there since they > are free to require any parameters to be added to the authorization > headers as stated in section 7 of the OAuth spec > <http://oauth.net/core/1.0/#rfc.section.7>. Is the only way around > that to create custom OAuth request handling depending on which > service provider we're connecting to? If so, that kinda stinks. > > Thanks, > Rich > > On Thu, May 7, 2009 at 7:57 PM, Kevin Brown <[email protected]> wrote: > > Set sign_owner and sign_viewer both to 'false' when issuing your request > and > > no non-standard parameters will be passed. If you're using 3 legged > oauth, > > you probably don't need these parameters anyway. > > > > On Thu, May 7, 2009 at 7:01 PM, Eiji Kitamura <[email protected]> wrote: > > > >> Hi, > >> > >> > >> I've encountered similar issue when trying to get tokens out of Twitter > >> OAuth. > >> They seem like rejecting my request because of extension parameter > >> "xoauth_app_url". > >> I found this because it did work when trying the same thing without > >> "xoauth_app_url" which I examined using shindig code. > >> > >> On the other hand, looking at OAuth spec, 9.1.1 Normalize Request > >> Parameters > >> http://oauth.net/core/1.0#anchor14 > >> > >> saying that all parameters must be concatenated except for > >> "oauth_signature" to make signature base string which I believe > >> is the problem, if I'm not misunderstanding. > >> > >> > >> Both Twitter and TripIt are using ruby? then I doubt the problem lives > >> in ruby oauth library. > >> This is just my guess though. > >> > >> Eiji, > >> > >> 2009/5/8 Richard Wallace <[email protected]>: > >> > Hey all, > >> > > >> > I'm trying to write a gadget that runs on our Shindig based container > >> > and have run into several hurdles along the way. You can read more > >> > about it on their forums, but the problem I'm having now is that I get > >> > to a point where I have an access token and try and fetch data, and > >> > when I do that Shindig adds the opensocial_* parameters and includes > >> > them when signing the request, which causes TripIt's OAuth provider to > >> > reject the request because it ignores those parameters completely and > >> > doesn't include them when calculating the signature. The details are > >> > on this thread < > >> > http://groups.google.com/group/api_tripit/browse_thread/thread/d41d54935b646438/771f24d3bda32352#771f24d3bda32352 > >> >. > >> > > >> > So, what is the solution for this? Is his argument valid? Do I need > >> > to include special handling in my container for TripIt to get it to > >> > work? Is this going to be a common theme when trying to access data > >> > protected by OAuth? It's starting to seem like there is really no > >> > "standards" in how to make OAuth requests or do the dance. Sure there > >> > are the basics, but the service providers are so free to specify > >> > additional parameters that a generic approach like the one taken in > >> > Shindig just can't work. > >> > > >> > Thanks, > >> > Rich > >> > > >> > > >
