Thanks for the response. I'm glad this isn't too common of an occurrence as I was getting a bit frustrated and concerned that this was going to be an ongoing problem that we would have to battle. I'll contact the people at TripIt again and let them know about the brokenness of their service (in as nice a way as I can). Hopefully the more people using OpenSocial and OAuth in general the more people will start to conform. I don't hold huge expectations as there are still strange compatibility issues even when trying to write SMTP clients and servers and that's a protocol that's been around a bit longer than OAuth.
Thanks again, Rich On Fri, May 8, 2009 at 11:28 AM, Brian Eaton <[email protected]> wrote: > On Fri, May 8, 2009 at 11:15 AM, Richard Wallace > <[email protected]> wrote: >> 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. > > Good thing most SPs don't do that, then. > > There are a fair number of SPs who fail signature checks on request > token and access token requests if there are extra parameters passed > along. Those SPs have been deemed broken [1], because they make it > impossible to extend the protocol in backward compatible ways. > However, those SPs aren't going to go away just because of OpenSocial. > Setting signOwner and signViewer to false will continue to give you a > plain vanilla OAuth consumer, no opensocial extensions. > > The other compatibility issue is with providers who have implemented > strange signature schemes. For example, PhotoBucket requires > consumers to send requests to hostnames like XX.api.photobucket.com, > but requires the signature to be on api.photobucket.com. They are > breaking the OAuth spec, and I haven't been able to figure out an easy > way to make Shindig compatible without hardcoding something like "If > the host is photobucket, go do some magic." The folks at PhotoBucket > have expressed a tentative willingness to accept both their custom > signature scheme and the vanilla scheme, so hopefully the problem will > just go away. > > [1] > http://www.hueniverse.com/hueniverse/2009/03/clarifying-oauth-requirements-for-service-providers.html >
