Would like to patch so that Oauth works with Yahoo. Preferred Way? about oauth HOT 8 CLOSED

Sorry, I should also note that it's hard to subclass that functionality in a separate package because of the need for access to Consumer attributes that aren't exported like sign_request , makeKey, and baseParams

from oauth.

Ok, this is crazy. It looks like you too have written code to access the Yahoo Sports API. However, I can't find where you deal with refreshing the auth-token? What am I missing?
Thanks,
Matt

from oauth.

Thanks a lot for the info! It would be great to make this work.

(Also: You're not crazy: the Yahoo API stuff I wrote cheats and requires you to re-authorize every time you run it.)

So the question is just how to implement this.

I'm not married to any particular solution, so feel free to exercise your judgement. Just brainstorming a bit, my initial reaction would be to add two features to the API:
(1) Have AuthorizeToken additionally return the body of the response
(2) Add something (similar to the "AdditionalAuthorizationUrlParams" hack for Netflix in GetRequestTokenAndUrl) which specifies additional key-values (on top of the standard OAuth ones) when making AuthorizeToken requests.

Then the client can parse the "oauth_session_handle" from the response body when calling AuthorizeToken in (1), and then set it back using (2).

If you're up for submitting a patch , I think it'd be a great addition.

• Matt

from oauth.

Ok, after thinking about it for a minute, that solution probably isn't sufficient since AuthorizeToken takes a verificationCode parameter, which won't be present/necessary on token refreshes.

I'm not sure I have a great solution right off the top of my head, but some ideas:

• It might work to just set the verification code to the empty string when refreshing, but it also might break things (and it's a kind of lame API also).
• We could add a RefreshToken method ... which is also kind of lame, since it seems like it's Yahoo-specific.
• Maybe there's a different layering of abstractions here, where we still expose just a couple, very simple methods for standard OAuth implementations, but expose some lower-level building blocks for communicating with those APIs that have quirks. These smaller blocks would probably be a little more work to use, but would give someone more control over how the OAuth communication unfolds.

I'll think about it some more. Let me know if you've got a good idea.

• Matt

from oauth.

I'll see if I can come up with something between Christmas and New Year.

On Sun, Dec 23, 2012 at 6:40 PM, Matt Jones [email protected]:

Ok, after thinking about it for a minute, that solution probably isn't
sufficient since AuthorizeToken takes a verificationCode parameter, which
won't be present/necessary on token refreshes.

I'm not sure I have a great solution right off the top of my head, but
some ideas:

• It might work to just set the verification code to the empty
  string when refreshing, but it also might break things (and it's a kind of
  lame API also).
• We could add a RefreshToken method ... which is also kind of lame,
  since it seems like it's Yahoo-specific.
• Maybe there's a different layering of abstractions here, where we
  still expose just a couple, very simple methods for standard OAuth
  implementations, but expose some lower-level building blocks for
  communicating with those APIs that have quirks. These smaller blocks would
  probably be a little more work to use, but would give someone more control
  over how the OAuth communication unfolds.

I'll think about it some more. Let me know if you've got a good idea.

• Matt

  —
  Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-11653448.

from oauth.

Was there any progress made here? I ran into the same problem with Yahoo's API and made the changes locally but I agree that a more general solution could be reached.

Here is where I am at so far: https://github.com/Forestmb/oauth/compare/feature;token-session-support.

• Stores all response values from the service provider into a key/value pair structure (aside from the token and secret which are handled separately)
• Added a new method RefreshToken which uses this additional information to perform the request without requiring re-authorization

I was leaning towards the RefreshToken approach but I agree it does seem Yahoo-specific (or OAuth Session-specific). However, if I just make makeAccessTokenRequest public (with a better name) a client could easily implement RefreshToken themselves.

from oauth.

Hi and thanks so much for working on this!

The code you linked to looks good to me. I agree it's unfortunate to support something so non-standard ... but, Yahoo seems important enough to get working natively even if it's not really the official protocol.

I don't know if there are any things you're still working on, but if you send me a pull request whenever you're done I'd be happy to merge it ... with just a couple small caveats:

• It's probably worth a comment on the new RefreshToken method noting that many service providers won't support this method (I guess they'll get a "Missing oauth_session_handle in access token" error). Maybe a link to the OAuth Session doc would be useful too.
• If it's not too hard, a test for RefreshToken in oauth_test would be great also.

Thanks again!

• Matt

from oauth.

This should be fixed now, feel free to re-open if anyone is having issues.

from oauth.