Re: [dotnetopenauth] Instagram seems to be dropping state parameter on the floor...

[Andrew Arnott]

I would suggest you start with contacting instagram telling them that their implementation is buggy and they should fix it.  In my experience, folks are usually pretty responsive to fixing their service when the spec is clearly different.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Sun, Jul 1, 2012 at 4:52 PM, JT <jt2...@gmail.com> wrote:

I have fb working fine but instagram throws a protocol exception using the exact same code.  Stepping through it, it appears that our state is not being returned in the url.  The original outbound URL looked like this:

 

https://api.instagram.com/oauth/authorize?client_id=[client_id]&redirect_uri=https%3A%2F%2Flocalhost%2FAccount%2FLinkAccountCallback%3Fservice%3Dinstagram&state=yagfvct1ke3pnyda0kcsjx2l&response_type=code

 

and the eventual redirected response request came back like this

https://localhost/Account/LinkAccountCallback?service=instagram&code=205a499946c849d894f14c2d27a5b989

 

So what it seems like is that I would need to be able to query the state value (which appears to be asp.net session id) and roll that into my callback uri prior to calling PrepareRequestUserAuthorization().  Otherwise, it seems that instagram won't send back the params that DotNetOpenAuth is internally adding outside of the redirect_uri context.

 

Any ideas?

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/4vIKzw8fIfUJ.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

[JT]

Hi Andrew,

 

Thanks for replying.  Unfortunately my post on the instagram developers google group isn't even getting approved (no errors, just never showing up).  Also, I see a similiar problem/question posted a year ago and it never got a reply.  I'm guessing they have bigger fish to fry or something.  To try to push forward I did a few things on my end.

 

First I tacked the state={HttpContext.Session.SessionID} string onto my callbackUri param.  This got me past the first issue but right into the next.  Your StripMessagePartsFromQueryString() call takes the state= part back out of the callbackUrl value.  So then when we call back to get the token and pass a different callback value the server gives 400. 

 

Now if I build the url by hand in the debugger and put my state= string back into the callback value for this second call we actually get back a successful response with an access token but then DeserializeJsonAsFlatDictionary throws an exception citing "the maximum read depth (2) has been exceeded because XML data being read has more levels of nesting than is allowed by the quota".  Apparently the returned JSON is upsetting.

 

"{\"access_token\":\"38478976.b0722de.2e3789c97bd14fb1b79a789f47d68e6c\",\"user\":{\"username\":\"myusername\",\"bio\":\"\",\"website\":\"\",\"profile_picture\":\"http:\\/\\/images.instagram.com\\/profiles\\/anonymousUser.jpg\",\"full_name\":\"My Full Name\",\"id\":\"123456\"}}"

 

So I just can't catch a break on this one! :-)

 

If you have any ideas or if I can supply any more info please let me know.

 

Thanks

-JT

On Sunday, July 1, 2012 6:55:44 PM UTC-5, Andrew Arnott wrote:

I would suggest you start with contacting instagram telling them that their implementation is buggy and they should fix it.  In my experience, folks are usually pretty responsive to fixing their service when the spec is clearly different.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Andrew Arnott]

Hi JT,

The fact that the service is sending back a richer-than-standard access token response (with a JSON object that contains sub-objects) isn't strictly against the spec, from what I can read from the spec.  So please file an issue asking for rich JSON objects in access token responses to be supported.

As for the state, that and combine it with the above issue, I recommend you (gasp) try putting DotNetOpenAuth aside and doing the client flow manually yourself.  OAuth 2 isn't that complicated for the client usually, and in this case it sounds like it may be less friction for you.

What do you think?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/v0cYKlBMUi8J.

[JT]

Sure, sounds reasonable.  I filed the issue just now.

 

Along the lines of the JSON responses...  with OAuth1/WebConsumer I get an authResponse back that includes an ExtraData field.  However in OAuth2/WebServerClient I don't see an analog.  So even if we weren't hitting the parsing exception I'm not seeing a way that I'd be able to access the contents of this JSON payload.   Is that correct?

 

-JT

[Andrew Arnott]

Probably correct.  This will have to get fixed with support for the rich object within it.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/ZoUa6_uRdPUJ.

[JT]

So the official response from Instagram was:

 

 

-----------------------

Hi all,

We do support GET params in the redirect_uri parameter (if that's not working, please let us know). You'll have to modify your library to support passing that state as part of the GET param if it currently does not.

--
Mike Krieger

Co-founder, Instagram

------------------------

 

I.e. "we're not adding support for the state param"...  so it would be nice if DotNetOpenAuth were able to deal with the state var being part of the redirect_uri field at some point.  Thoughts?

 

 

[Andrew Arnott]

Was this reply on a public forum that I can contribute to?  I'd like to drill in a bit more on this.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/SrhK0_y3cVcJ.

[John Bradley]

They must support state to conform to OAuth 2.0.  

There are security reasons not to pass state in query parameters. 

Google and many other providers won't allow it. 

Variable query parameters are allowed but not required to be supported.

In OAuth. 

John B.  

Sent from my iPad

[JT]

Yes, it was on the instagram API developers google group... hopefully this link will work:

 

https://groups.google.com/forum/?fromgroups#!topic/instagram-api-developers/JEyUwrnhozo

 

You may have to join the group first:

 

https://groups.google.com/forum/?fromgroups#!forum/instagram-api-developers

 

Good luck and thanks for looking into this!

[Andrew Arnott]

I've replied to the forum.  John, if you can add the security considerations as to why a redirect_uri query parameter is insufficient, I'd be interested, and it may help add weight to the forum post.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/0rrbmAizBe8J.

[JT]

Dang, they actually fixed it.  He replied to your post and now I'm seeing the state param come back.  Now DNOA is puking on that XML depth bug that I posted previously.