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:
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.
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%2FLinkAccountCal lback%3Fservice%3Dinstagram&state=yagfvct1ke3pnyda0kcsjx2l&response_type=co de
> and the eventual redirected response request came back like this
> 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 dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
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.
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
> 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%2FLinkAccountCal lback%3Fservice%3Dinstagram&state=yagfvct1ke3pnyda0kcsjx2l&response_type=co de
>> and the eventual redirected response request came back like this
>> 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.
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 <https://github.com/dotnetopenauth/dotnetopenauth/issues> 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
On Mon, Jul 2, 2012 at 11:02 PM, JT <jt2...@gmail.com> wrote:
> 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
>> 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:
>>> 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 PrepareRequestUserAuthorizatio**n().
>>> Otherwise, it seems that instagram won't send back the params that
>>> DotNetOpenAuth is internally adding outside of the redirect_uri context.
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
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?
On Tuesday, July 3, 2012 8:43:53 AM UTC-5, Andrew Arnott wrote: > 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 <https://github.com/dotnetopenauth/dotnetopenauth/issues> 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
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
On Tue, Jul 3, 2012 at 7:57 AM, JT <jt2...@gmail.com> wrote:
> 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
> On Tuesday, July 3, 2012 8:43:53 AM UTC-5, Andrew Arnott wrote:
>> 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 <https://github.com/dotnetopenauth/dotnetopenauth/issues> 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
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
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?
On Tue, Jul 10, 2012 at 12:41 PM, JT <jt2...@gmail.com> wrote:
> 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?
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
> 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
> On Tue, Jul 10, 2012 at 12:41 PM, JT <jt2...@gmail.com> wrote:
> 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?
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.
On Tuesday, July 10, 2012 5:03:19 PM UTC-5, Andrew Arnott wrote: > 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
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
On Wed, Jul 11, 2012 at 9:08 AM, JT <jt2...@gmail.com> wrote:
> Yes, it was on the instagram API developers google group... hopefully this
> link will work:
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
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.
On Friday, July 13, 2012 9:28:03 AM UTC-5, Andrew Arnott wrote: > 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
