Back to Fantasy Sports API Forum
0

Storing User Credentials

I have a strong desire to store user credentials, so I can authenticate behind the scenes, so I can use the services on devices where manual user input isn't convenient.

Here is what I want.

I make a screen that provides all the terms and conditions that Yahoo requires,

they store their information

and accept that the application will gain access to their data, much like they do right now.

Then when we load the application , we can authenticate BAU, without having to bother them about it every time they access the application.

This device has a few issues,

1, it doesn't support normal web pages (it is a strict xhtml browser, but I dont know what type of support it has for forms)
2. its interface is optimized for selecting things, user input is really akward, and at best, would be via onscreen keyboard

How is this accomplished? I see applications for things like this being on handhelds or cell phones.

Is there a way to post user credentials, and to accept sharing information directly? without the user having to enter it on a form and pressing the OK button?

Any insight on this matter is of course greatly appreciated.

by
Report Abuse
13 Replies
  • Maybe I'm asking the wrong question

    it might be acceptable in my case, to have the user register with a browser the first time,

    are the access tokens produced able to be used indefinitely for that user? Or do they have to long in and accept every time they run it?

    I could see maybe storing the token hashes in a database and providing them with the calls.

    Would this be the proper way of doing this?
    Report Abuse
    0
  • I think you're asking about the expiring Yahoo OAuth access tokens. I've not worked out the workflow involved in [efficiently] refreshing these tokens, but it is possible and here's some related information: http://developer.yahoo.com/oauth/guide/bk01ch05s07.html

    Perhaps others will weigh in on this, as I'm still getting used to OAuth in general.
    Report Abuse
    0
  • OK, so realistically, if you had a site or something set up that wanted to use it longer than an hour, you would have to hit the get_token every i dunno, 45 minutes or so, which would issue a new token, valid for an hour.

    Then you would simply overwrite the token in the database.

    And if your app went offline, youd have to have the users re-authenticate access to their data.

    That about right?

    Thanks for the response by the way. =)
    Report Abuse
    0
  • QUOTE (Sam Coder @ Jun 22 2010, 07:50 AM) <{POST_SNAPBACK}>
    OK, so realistically, if you had a site or something set up that wanted to use it longer than an hour, you would have to hit the get_token every i dunno, 45 minutes or so, which would issue a new token, valid for an hour.

    Then you would simply overwrite the token in the database.

    And if your app went offline, youd have to have the users re-authenticate access to their data.

    That about right?

    Thanks for the response by the way. =)


    To refresh your credentials for a user you have to input in their old access_token, access_token_secret, and session_handle. So be sure to save these to a database. After you query for new credentials, update your database with the new values.

    You can keep track of the time of last access, or you can just ask for access and if Yahoo says to entire valid credentials, grab new ones.
    Report Abuse
    0
  • Yeah, I have a funny way of talking, but that's what I was implying.

    Thanks for the clarification,
    it's really too bad that they don't allow 'unlimited' tokens for this service though, I can see that other Yahoo Services do allow unlimited tokens.

    I wouldn't have thought fantasy sports data to be considered really that critical or anything.

    Anyways, this may be the way I have to approach the whole thing,

    Thanks again
    Report Abuse
    0
  • QUOTE (Sam Coder @ Jun 22 2010, 02:51 PM) <{POST_SNAPBACK}>
    Yeah, I have a funny way of talking, but that's what I was implying.

    Thanks for the clarification,
    it's really too bad that they don't allow 'unlimited' tokens for this service though, I can see that other Yahoo Services do allow unlimited tokens.

    I wouldn't have thought fantasy sports data to be considered really that critical or anything.

    Anyways, this may be the way I have to approach the whole thing,

    Thanks again


    I think a lot of fantasy players are more concerned with the safety of their fantasy teams than that of their bank accounts. Their is no fraud protection on your fantasy team. But more to the point, the lack of unlimited token isn't really a huge thing assuming your code can refresh the token. As was mentioned above, you can either catch the expired error and refresh or just refresh every time you need to make a request. Your user need never know, and really as long as the user isn't affected then it's all good.
    Report Abuse
    0
  • Yeah, Well, I guess your point is valid, I'm looking at this from another perspective.

    If my application goes down for any reason for longer than an hour, than all users who use the application have re-authenticate.

    This wouldn't be a problem at all, assuming that I could just post the login, then post the acceptance

    My concern is that on my platform, the web page may not be possible, and ideally, I would want to allow them to re accept with a click.

    To be clear, my platform is embedded, no web browser is accessible.

    I would need to either have a user log into an account via computer (highly undesirable)
    or I would have to make a user interface allowing them to post their credentials and information sharing acceptance..

    At the moment, it looks like the only way I could achieve that is via screen scraping, and again... highly undesirable. In fact, I'd prefer the web browser approach, even if it meant that they would have to dig out the laptop.. =)
    Report Abuse
    0
  • QUOTE (Sam Coder @ Jun 23 2010, 04:54 AM) <{POST_SNAPBACK}>
    Yeah, Well, I guess your point is valid, I'm looking at this from another perspective.

    If my application goes down for any reason for longer than an hour, than all users who use the application have re-authenticate.


    So there's where you are wrong, I believe. According to this doc, at least, if you go down for over an hour you are guaranteed to have an expired token, but if you have stored the appropriate information related to the access token (which you should do as soon as you get it), you just use that to refresh your token, no user intervention required. Do you disagree with that interpretation of the doc? I've mentioned this point a couple of times before but it seems to be getting overlooked or misunderstood.
    Report Abuse
    0
  • I think the point needs clarification however, because for example it begs the question of why do these expire at all? As it seems to only add pain to the developer, who can seemingly refresh the tokens anytime. And as for anytime, is their a real time limit? Like, let's say a week or month or year from now, can the token simply be refreshed without user intervention?
    Report Abuse
    0
  • Okay, I now see that oauth_authorization_expires_in is a huge number, so it's essentially forever (~27 years). However, I still wonder why it expires at all. I assume there's a security benefit, so would like to understand it a bit better.
    Report Abuse
    0
  • QUOTE (phil @ Jun 24 2010, 05:19 PM) <{POST_SNAPBACK}>
    Okay, I now see that oauth_authorization_expires_in is a huge number, so it's essentially forever (~27 years). However, I still wonder why it expires at all. I assume there's a security benefit, so would like to understand it a bit better.


    The expiration for fantasy sports is one hour, but I agree, it doesn't make a lot of sense to have it expire when it can be automatically refreshed. Perhaps there is something I'm missing, but I dunno.
    Report Abuse
    0
  • The token expires after one hour because if someone (a hacker) somehow steals the token, he/she has access to the user's data for at most an hour.

    Sam Coder, your users will need to go through a browser first to sign in to Yahoo! and grant you permission to their Fantasy Sports data, as part of the OAuth process. After that, you'll get an access token, token secret, and session handle (as shown here). Phil, brant, and Jay are all correct. Just save those three things in your database, and you can refresh the access token and get access to the user's data at any time, essentially forever. The user won't need to go through the authentication process again.

    I believe what you want to do is possible. If your app, running on an embedded device, has access to those three things stored in your database and your consumer key, it can access our data. However, without a browser on that device, how will you know who the user is?
    Report Abuse
    0
  • Jay, phil, Shane,

    Thanks,

    Jay, not purposely missing your point, just misinterpreting I guess.

    Thanks for being persistent.

    So rather than have a process that keeps refreshing tokens, it would make more sense to have an expired token error message simply call the get_token again.

    Makes much more sense,

    Thanks for clarifying this guys, very much appreciated.
    Report Abuse
    0
Ask a Question

Recent Posts

in Fantasy Sports API