SBJSON error

[Paul Capestany]

Hey there,

I've gotten the Buzz and DailyMotion examples to work just fine in the
OAuth2SampleTouch app, but when I change clientID/Secret and the token
and auth URLs, for different services (I've tried Facebook and Github,
which both use Oauth2) I get the following error:


SBJSON error Error Domain=org.brautaset.JSON.ErrorDomain Code=3
"Unrecognised leading character" UserInfo=0x8048c10
{NSLocalizedDescription=Unrecognised leading character} parsing
access_token=776220ed71xxxxxf0ebe7db79&token_type=bearer


Are we supposed to do anything differently to plug in other services?
Not sure if I'm missing something straightforward..

[Greg Robbins]

I believe that Facebook does not support OAuth 2 in a way that is similar to the current drafts of the standard. In particular, the Facebook servers return a form body response, but the spec requires a JSON body response.

http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.1.4

[Paul Capestany]

Thanks for the super-quick response Greg!

Github appears to have the same problem :(

I added a couple lines of code to detect whether the response
containing the accesss_token is valid JSON or not (and convert it to
JSON if it's not) but am still unable to make authorized requests to
those APIs. I'm an oauth newbie so still trying to figure things out I
guess..

Is there any sort of similar backup strategy that you guys were
thinking of implementing in the works in case 3rd parties aren't
following the full draft of the Oauth2 spec yet?

[Greg Robbins]

Right now, we're still being optimistic that service providers will catch up quickly. Facebook is a major contributor in the OAuth 2 standard development.

[Paul Capestany]

Yeah, one would hope so, I'll be hacking up workarounds till then I
guess :)

Regardless, thanks for the code you guys are providing with both the
Oauth and Oauth2 controllers. Really appreciate that (as well as your
awesome responsiveness)!

[Ivo Jansch]

Hi,

I ran into the same issue as the original topic poster. Considering
we're a few months further but some OAuth2 providers are still sending
responses in http form I wrote a patch for gtm-oauth2 that looks at
the response header and either decodes the JSON or the http form
fields.

The patch can be found here:

http://code.google.com/p/gtm-oauth2/issues/detail?id=1

Greetings,
Ivo

[Greg Robbins]

I don't want to send the library in the direction of trying to support a variety of pre-spec implementations, but Ivo's patch is simple enough that I've incorporated a version of it into the library.

http://code.google.com/p/gtm-oauth2/source/detail?r=57