Handle the removal of offline_access

[GoogleCodeExporter]

https://developers.facebook.com/roadmap/offline-access-removal/

Facebook had deprecated the offline_access token, so client libraries should 
accomodate the change.

Original issue reported on code.google.com by bozhidar...@gmail.com on 3 May 2012 at 1:18

[GoogleCodeExporter]

Thanks, I had a mental TODO to make a bug for this - you've saved me some 
effort :)

I'll need to update the docs on restfb.com too.

Original comment by m...@xmog.com on 3 May 2012 at 1:52

• Changed state: Accepted
• Added labels: Milestone-Release1.6.10

[GoogleCodeExporter]

You'll also need to add a method for extending the token's expiration date, via:

https://developers.facebook.com/roadmap/offline-access-removal/#extend_token

I haven't tested this, but based on similarities to 
convertSessionKeysToAccessTokens() I suspect the method would look something 
like:

public String extendAccessToken(String appId, String secretKey, String 
accessToken) {
    verifyParameterPresence("appId", appId);
    verifyParameterPresence("secretKey", secretKey);
    verifyParameterPresence("accessToken", accessToken);

    String newToken =
        makeRequest("/oauth/access_token", true, false, null, 
            Parameter.with("client_id", appId),
            Parameter.with("client_secret", secretKey), 
            Parameter.with("grant_type","fb_exchange_token"),
            Parameter.with("fb_exchange_token", accessToken.getAccessToken())
            ));
    return newToken;
}

Original comment by ibex...@gmail.com on 23 May 2012 at 9:30

[GoogleCodeExporter]

Even better would be to have a public getExtendedToken that uses an existing 
client's accessToken value.

Original comment by ibex...@gmail.com on 23 May 2012 at 11:48

[GoogleCodeExporter]

Hey, thanks for the patch, I appreciate it!  I'll adapt this into 1.6.10.

Original comment by m...@xmog.com on 24 May 2012 at 8:32

[GoogleCodeExporter]

I'm not 100% sure the proposed scheme will work. At the above URL 
https://developers.facebook.com/roadmap/offline-access-removal/#extend_token it 
says  

"If you would like to refresh a still valid long-lived access_token, you will 
have to get a new short-lived user access_token first and then call the same 
endpoint below. "

Presumably, the access token stored in the FacebookClient object on the server 
side will be a long-lived access token.  If so, the above comment implies that 
you first have to get a new short-lived access token before you can get a 
refreshed extended long-lived access token.

I hope we can just call the above proposed extendAccessToken, but it seems as 
if somehow you first have to get a new "short-lived" access token.  

It's not immediately clear to me how you are supposed to do this on the server 
side.

Original comment by jjdemp...@gmail.com on 29 May 2012 at 4:18

[GoogleCodeExporter]

You don't get the short-lived token server-side.  The workflow would be 
something like:

// ... client auths with FB and provides token to server via cookie 
//     or some other means
DefaultFacebookClient client = new DefaultFacebookClient(token);
String newToken = client.extendAccessToken(appId, secretKey);
// ... store newToken in database for later use?
client = new DefaultFacebookClient(newToken);
// ... continue working

Or if you were to take my example as a static method:

String newToken = DefaultFacebookClient.extendAccessToken(appId, secretKey, 
token);
client = new DefaultFacebookClient(newToken);

Original comment by ibex...@gmail.com on 31 May 2012 at 6:10

[GoogleCodeExporter]

It will make my day if that's the way it works, ibex...@gmail.com.  Thanks.

I'm just not sure how that workflow is consistent with the quote in Comment 5 
above.

--Jim--

Original comment by jjdemp...@gmail.com on 1 Jun 2012 at 2:17

[GoogleCodeExporter]

The quote in comment 5 just means that if you try to extend a token that is 
already long-lived, nothing will happen (even if it's about to expire).  
Facebook wants to prevent you from extending user tokens indefinitely, so they 
only let you create a single long-lived token off of the default short-lived 
ones.

I've also noticed that they don't allow you to extend the auth tokens of app 
test accounts (which seem to default to 1-day expirations, so maybe their 
system already counts them as long-lived).  If you request an extension for 
these, the original token is returned.

Anyway, if you would like to check it out, this and a couple other changes are 
now tracked here:

https://github.com/revetkn/restfb/pull/9

Original comment by ibex...@gmail.com on 2 Jun 2012 at 12:31

[GoogleCodeExporter]

Does this mean you can extend an access token without sending a users browser 
to Facebook?  The docs seem to imply that the user has to visit your app in 
order for a token to be renewed, and effectively "sent" through the 
authentication process again.

That code seems to imply that you can extend a access token from the server 
without user involvement?  Unless I'm missing something.

Original comment by evan.gil...@gmail.com on 12 Jun 2012 at 10:10

[GoogleCodeExporter]

This is fixed in 
https://github.com/revetkn/restfb/commit/b1f2de52a07a42925eccecb0a801974016c9040
1

Original comment by m...@xmog.com on 2 Sep 2012 at 4:21

• Changed state: Verified