The application which I am building maps a user_id to multiple facebook accounts. I have access tokens for each of these mapped accounts and everything works nicely. There is a problem, though, when one of these access tokens expires but the user is logged in to Facebook as a different user than the one to whom the expired access token belongs.
I read all there is about obtaining a new access token for the currently logged in user but I found nothing about the case when the user whose access token expired is not logged in to Facebook.
I would appreciate your thoughts and possible solutions.
Users can't have multiple Facebook accounts, so that part of your question doesn't entirely make sense, but in general, if an access token expires you need the user to come back to your app and go through the Authentication flow again, which will give you a new access token for that user
I believe the only way to get an updated access token would be to go through the whole authentication process again from the initial login screen.
Depending on the technology with which you're building your application, the only way I can imagine you'd handle logging in to a Facebook account without logging out of an existing one is to set up parallel instances of web browsers, so long as they don't share things like cookies.
Related
How can I retrieve the user access token programatically? I want to refresh the token before it expires through program. How do I achieve this using facebook4j or spring social facebook?
Refreshing tokens is only possible on user interaction. There is no way to do that programmatically, the whole point of short living tokens is that it´s NOT possible to just get a new one without user interaction.
I have an application, that runs on server. On that server is background task, that will post status update on few social networks (Facebook, Twitter, G+). It must be completely server-side.
In Twitter API I'm able to use OAuth header to authorize API request. OAuth HTTP header uses consumer key, consumer secret, access token and access token secret to create the header. With this I'm able to post/update/delete tweets with no user interaction.
How can I do this for Facebook? I found a solution to obtain a long-lived access_token (2 months), but we don't want to regenerate access_token every 60 days. We want to use it for manage our Facebook page - post status updates, but completely server-side.
Am I able to do this for Facebook? Thanks for answers.
PS: I searched stackoverflow hundred-times but with no solution for my problem.
Thanks.
It is not possible for User Access Tokens (they can only be extended to 60 days and need to be refreshed by the user after that), but for posting to a Page you should use a Page Token anyway. An Extended Page Token is valid forever.
Here are some Links to help you get that Extended Page Token:
https://developers.facebook.com/docs/facebook-login/access-tokens/
http://www.devils-heaven.com/facebook-access-tokens/
http://www.devils-heaven.com/extended-page-access-tokens-curl/
A Page Token will post "as Page" btw, but that´s probably what you want. And auto-posting on user profiles is not really allowed anyway, every message has to be 100% user generated and every posting should get authorized by the user.
Pay attention to Access Tokens Expiration & Extentions.
The Page Access Token could be a good solution to only server side calls for testing and data analysis purposes.
Take your User Access Token from Graph API Tool
Extend your User Access Token
Call https://graph.facebook.com/v2.11/me/accounts with your user access token extended
*all calls are GET and this procedure does not use APP Access Token.
The situation is still unclear for me – After July 5th 2012, will desktop application be able to have access to Facebook data if user, associated with access token, logged out from Facebook?
Are talking here about TOTAL deletion of offline access AT ALL or just limitation for offline access by 60 days?
Document - https://developers.facebook.com/roadmap/offline-access-removal/ doesn’t give clear answer (IMHO). Quote: “Once the migration setting has been enabled, Desktop applications will automatically get user access_tokens returned that have the longer expiration time. However, there is no way to get a long-lived user access_token without having the user login to your app again.”
As of April 30 I’m able to request access token WITH ‘offline_access’ permission for desktop application (using URL: https://graph.facebook.com/oauth/authorize?client_id=APPLICATION_ID&redirect_uri=http://www.facebook.com/connect/login_success.html&scope=manage_pages,read_stream,publish_stream,offline_access
) . And everything work fine. Even if user logged out. In spite of “Remove offline_access permission” was enabled for the application.
Your answers will be very much appreciated.
Just completed a patch to accommodate these changes. At least in my experience, we were working within a web app where renewing the access tokens was as simple as changing everything over to the Javascript SDK and relying on the browser's login state. This seemed a much more logical approach than cross-checking a server-side saved long-expiry access token with every action to see if it was still good.
Essentially, what is going to happen for desktop implementations is the access tokens will be longer-lived by default, but still require the renewal at the end of the sixty day period. You should have logic in your app that will check that validity of the access token with facebook before taking action with it (or just try and fail with a prompt) and then prompt the user to login and revalidate if the access_token has expired. So long as this logic is in place the access tokens that expire will trigger re-validation.
If your app receives short-expiry access tokens...
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. The returned access_token will have a fresh long-lived expiration time, however, the access_token itself may or may not be the same as the previously granted long-lived access_token.
Short-lived access tokens, the kind that only last for a session until logout, are going to need to be converted to the sixty-day, long-expiry access tokens using the endpoint documented in that article. Desktop apps configured to the new setting will receive these kind by default, but these will still need to be regenerated with a new login after 60 days.
I agree that this is a lot clumsier to implement, especially for desktop apps, but it is certainly a lot more secure from facebook's standpoint. If you start to think of the access token as a transient rather than permanent access credential and start changing your logic to check validity via curl or some other http post mechanism, rather than referencing your database, you'll have a much easier time with the adjustment. Don't allow your architecture to assume that the presence of a saved access token guarantees access, and be sure to cross check them over to the facebook endpoints and prompt for re-login where necessary.
Do Facebook APP access tokens expire? These tokens are different than the USER tokens; they are acquired like this:
https://graph.facebook.com/oauth/access_token?grant_type=client_credentials&client_id={0}&client_secret={1})
as described in the App Login section of the document at http://developers.facebook.com/docs/authentication/.
Are there any circumstances under which they will become invalid?
NB: This is NOT a question about USER access tokens (which are clearly documented). There was an identical question http://facebook.stackoverflow.com/questions/7322063/does-app-login-access-token-expire wrongly closed as duplicate of another question about USER access tokens.
Per the Facebook documentation:
An App Access Token is signed using your app secret and will not
expire; it will be invalidated if you re-key/reset your application
secret.
Creating an APP_ACCESS_TOKEN is really easy.
You can use your App ID/API Key and App secret
access_token = YOUR_APP_ID|YOUR_APP_SECRET
Example: 1234587968 | bghyuifjk3438483249235903502035023504305
I do know that one condition that will cause them to become invalid is if you reset the Application Secret using the Facebook developer tool.
I do not know if using the OAuth method to produce an App Token will cause it to have an expiration. However, if you scan Facebook's PHP SDK, you may notice that a non-expiring app token is made by concatenation app_id and secret:
/**
* Returns the access token that should be used for logged out
* users when no authorization code is available.
*
* #return string The application access token, useful for gathering
* public information about users and applications.
*/
protected function getApplicationAccessToken() {
return $this->appId.'|'.$this->apiSecret;
}
WARNING: I would never use this in client-code as it would publish your app secret. However, in a trust server environment, it seems like the way to go.
To test this, I went to the OpenGraph tool and erased my Access Token and typed in the concatenated value from the code sample. I then accessed my app's insights to verify that it would work:
<APP_ID>/insights/application_active_users
For me, the answer is not to find a token that doesn't expire, (since I do not trust Facebook), but to catch the expiring token and reset without taking up my users time. I found this and thought you might want to check it out.
"To ensure the best experience for your users, your app needs to be prepared to catch errors for the above scenarios. The following PHP code shows you how to handle these errors and retrieve a new access token.
When you redirect the user to the auth dialog, the user is not prompted for permissions if the user has already authorized your application. Facebook will return you a valid access token without any user facing dialog. However if the user has de-authorized your application then the user will need to re-authorize your application for you to get the access_token." Resource: https://developers.facebook.com/blog/post/2011/05/13/how-to--handle-expired-access-tokens/
I'm playing around with Facebook Connect, trying to use Facebook as the means or authentication on my site. Currently my workflow looks something like this:
Go to URL
Server checks cookies for AccessToken
If AccessToken exists, automatically fill in user's name/profile picture in comment box, and leave AccessToken in hidden input
send page down to client
on submit, verify access token (which was submitted with the rest of the form) is a valid access token for a real person. If so, add comment to Database
refresh page to display new data
if no access token, replace user's name/profile picture with <fb:login-button>, along with the required <script>s.
send page down to client
When user authorizes page/logs into facebook, refresh page
(go back to top, except this time the access token should exist)
So I have a few questions:
Is this secure? I was thinking of ways i would be able to do without the double authentication with Facebook (checking once on page-generation and checking again on comment-submission), and I could not figure any other way short of maintaining my own session-state with each client. Is that worth doing?
Does the access token expire when i log out of Facebook? I'm thinking it should, but it seems I can continue to use the same access token to grab data (i.e. name, url, etc.) after I manually go to Facebook and log myself out. Is it because I'm only asking for public information, and only more intrusive permissions expire on logout?
Given that each person who wants to do something has to provide a unique token from Facebook, this should have the side effect of blocking CSRF, since every action can be traced to a valid Facebook account. Is that right?
Why don't you just use the Facebook Javascript SDK to detect if they're currently logged into Facebook? This will also make the access token available in Javascript so you can make client-side calls to the API.
You can access the same access token server side via the session cookie set by Facebook also.
I can't answer all of your questions but I can tell you that having the access token in a hidden field on your page is risky from a policy perspective, especially if your page can be read by any third-party code such as Google Analytics or AdSense. Facebook will nail you for this as it is leaking user identifying data to third parties. The Facebook userid is in the access token in plain text. Facebook has automated processes that scan for this stuff and will auto-ban your app if it is leaking userids to third parties.