Databases
StackOverflow2013
Postsdbo
POHow to handle Facebook's deprecation of offline_access when you use token both in both iOS app and a server
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POHow to handle Facebook's deprecation of offline_access when you use token both in both iOS app and a server
    primarykey
    data
    text
    <p>Facebook's <a href="https://developers.facebook.com/roadmap/offline-access-removal/" rel="noreferrer">deprecation</a> of the <code>offline_access</code> permission is coming May 2012 and the documentation isn't giving us enough information on how to handle it.</p> <p>We have an iOS app and corresponding service that powers it and integrates with Facebook in a deep way to leverage a user's friend list within out app (so if your FB friends are also using the app you can more easily connect). This is like how all social apps seem to work, so nothing special here.</p> <h2><strong>Client</strong></h2> <p>Our app uses <a href="https://github.com/facebook/facebook-ios-sdk" rel="noreferrer">Facebook iOS SDK</a> to allow user to login, which we currently ask for <code>offline_access</code>. The token is persisted in our iOS app, but also sent to our server where it is saved. The client acts on behalf of user to post updates to a user's newsfeed (we also ask for <code>publish_stream</code> permission). </p> <h2><strong>Server</strong></h2> <p>Our server periodically checks to see if user's FB friends are now using our app. Next time user signs in, we expose content and relationships in a certain way to promote that user's friends. The server also acts on behalf of the user to periodically connect to the graph API and get the user's current friends list. This is so we can account for changes in a user's relationships and have them reflected in our app. We do this when the user isn't currently using the app so they have the best experience the next time they do use it. To enable this, our iOS app sends the access token to our server which it uses and why we ask for <code>offline_access</code>. </p> <p><strong>Note:</strong> If user signs out of our app explicitly, we delete the access tokens from both client and server.</p> <h2><strong>Problems</strong></h2> <p>Now that there is no longer a perpetual access token we can use, I'm trying to figure out the best practice for still enabling our scenarios while leveraging facebook's new intended way of handling and extending access tokens. The documentation is unfortunately not totally helpful.</p> <h2><strong>Questions</strong></h2> <p><strong>A.</strong> When you authenticate through the newest Facebook iOS SDK, what is the default lifetime of the access token you get? <a href="https://developers.facebook.com/roadmap/offline-access-removal/" rel="noreferrer">This document</a> says an extended token request will give you one that lasts 60 days. This <a href="https://developers.facebook.com/docs/authentication/" rel="noreferrer">other document</a> talks about the first access token request and mentions varying validities but it's <a href="https://developers.facebook.com/bugs/258370397568648?browse=search_4f22d5570e9499881039467" rel="noreferrer">unclear</a> and does it talk about specific validity times:</p> <p>(emphasis is mine)</p> <blockquote> <p>When you obtain an access token from Facebook, it will be valid immediately and usable in requests to the API for some time period defined by Facebook. After that period has elapsed, the access token is considered to have expired and the user will need to be authenticated again in order for your app to obtain a fresh access token. <strong>The duration for which a given access token is valid depends on how it was generated.</strong></p> <p>There are also events which may cause an access token to become invalid before its expected expiry time. Such events include the user changing their password, an application refreshing it's App Secret. Dealing with varying access token expiry times, and handling the case when an access token becomes invalid before its expected expiry time is essential for building robust social experiences.</p> </blockquote> <p><strong>B.</strong> For the client, now that the access token isn't necessarily long lived, is the right approach for us to: </p> <p>Let use login through FB, then detect whenever the access token is expired. If it is, then call into FB iOS SDK to re-authentication/re-authorize? (this should just trigger user to bounce out to FB iOS app, and in most cases come immediately back to our app with a new access token).</p> <p><strong>C.</strong> According to <a href="http://dominicminicoopers.blogspot.com/2012/03/facebook-access-tokens-and-offline.html" rel="noreferrer">this blog post</a> I found, you can only extend an access token once:</p> <blockquote> <p><strong>Can I exchange my 60 day access token for a new 60 day access token?</strong></p> <p>No, sorry you cannot. You can only exchange a valid (meaning current) user access token for an extended one. You cannot extend an already extended access token.</p> </blockquote> <p>On the client, I can just handle this by prompting a re-authentication/re-authorization as I mentioned in Question B. However, this doesn't work on our server. We could certainly have the server renew it once to 60 days, but what happens on the 61st day? The server just stops being able to sync the friend's list?</p> <p><strong>D.</strong> It seems to make sense to check the validity of the FB access token every time the app starts or re-hydrates from sleep. What is the best way for our iOS app to check this? Is there a recommended endpoint to call to validate a token? Should we just call into <code>https://graph.facebook.com/me</code> passing the access token and checking the response?</p> <p>Note: we can certainly record the <code>expires</code> time when we get the initially extended token, but this isn't reliable since the user could revoke our app's permission anytime which makes the <code>expires</code> time an unreliable data point on validity</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USTMC
    1. USTMC
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POHow to handle Facebook's deprecation of offline_access when you use token both in both iOS app and a server
      1. USAli Hamze
      1. VTFavorite
    2. VO
      singulars
      1. POHow to handle Facebook's deprecation of offline_access when you use token both in both iOS app and a server
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POHow to handle Facebook's deprecation of offline_access when you use token both in both iOS app and a server
      1. This table or related slice is empty.
      1. VTUpMod
    1. COIm also looking for the answer to B. At the moment FB is giving me access tokens that last 2 hours on iOS. Does this also mean I should stop trying to get [Facebook extendAccessToken] and [Facebook extendAccessTokenIfNeeded] to work as now they are defunct?
      singulars
      1. POHow to handle Facebook's deprecation of offline_access when you use token both in both iOS app and a server
      1. USnbransby
    2. CO@TMC instead of "polling" periodically for friends that add the app, might you be able to "push" that data when you get a new user? If this is your only use of offline access tokens, then it might be an alternative workaround to implementing the new offline_access stuff.
      singulars
      1. POHow to handle Facebook's deprecation of offline_access when you use token both in both iOS app and a server
      1. USlogan
    3. CO@logan: Our server polls FB periodically to check for changes in friends list and also monitors our system to see if any of your friends have signed up. We then do some auto-following between friends to make the app more engaging. I don't see how pushing data would work.
      singulars
      1. POHow to handle Facebook's deprecation of offline_access when you use token both in both iOS app and a server
      1. USTMC
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload