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.
Related
I am hitting a wall while developing seamless integration of a Facebook page with my bot.
Essentially I want to achieve same integration than Chatfuel or Manychat have, where being logged in with your Facebook account lets you to just choose what page you are connecting to them and you are good to go.
The problem I am facing is generating the proper token in order to bind the selected page to my app (bot). As per Facebook documentation:
When you create a subscribed_apps edge, the page-id you use in endpoint must match the page ID of the page access token used in the API call. The app that the access token is for is installed for the page.
Given the call has no other parameter than the access token, this access token has to be enough for Facebook to:
Authorize the action on the page.
Identify what app is being subscribed to the page.
This is confirmed while using the Facebook Graph API Explorer, where one selects the page and the app to bind and a proper access token is generated:
This token properly works using cURL in the terminal:
$ curl -X POST 'https://graph.facebook.com/v3.0/<MY_APP_ID_HERE>/subscribed_apps?access_token=<TOKEN_PASTED_FROM_GRAPH_API_EXPLORER>'
{"success":true}
With the Facebook Access token debugger (info icon on the left of the access token, then open in Access token tool), it is confirmed that the token knows about both the page and the app that have to be connected.
The question is, how are these page-app related token programmatically produced? I can't seem to find the proper API call in Facebook documentation and it is by all means possible, as Chatfuel and Manychat are doing this.
Thanks in advance for your support Lars Schwarz and community!
Adding some detail to Alex's answer, for it to be more complete.
When subscribing an app to a page, Facebook needs to:
Know what app you are talking about.
Know what page you are talking about.
Know that you have permissions on that page to subscribe an app.
How does Facebook know it all?
1 comes from the fact that Facebook login happens in the context of a page, actually, the Javascript code for Facebook contains your appId:
js.src = 'https://connect.facebook.net/en_US/sdk.js#xfbml=1&version=v3.0&appId=<YOUR_APP_ID_IS_HERE>&autoLogAppEvents=1';
2 Comes from the page_id in the URL used to subscribe apps to pages:
https://graph.facebook.com/v3.0/YOUR_APP_ID_HERE/subscribed_apps?access_token=YOUR_ACCESS_TOKEN_HERE
3 Comes from the access token, obtained in the context of an APP through Facebook login, that is passed as parameter in the URL used to subscribe apps to pages:
https://graph.facebook.com/v3.0/YOUR_APP_ID_HERE/subscribed_apps?access_token=YOUR_ACCESS_TOKEN_HERE
To do this, you need to put FB Login on your site/customer portal and request pages_messaging and manage_pages permissions. The person that logs in must be a Page Admin.
Once your app has been granted that permission for the page, you can generate a page access token as described here:
https://developers.facebook.com/docs/pages/access-tokens
My app got white-listed for using the Ads API.
I was wondering in regarding to the authentication flow.
Say, that I need to retrieve and execute actions via the API on daily tasks ( with no user interaction) , I find the authentication process quite cumbersome.
Is there a way to work with my app access token instead of a user access token?
I want to be able to approve my app only once for each user and then to be able to work with no user interaction.
Can I achieve this?
App access token is not relevant for this case.
I had to work with the user access token.
I followed this doc: https://developers.facebook.com/docs/reference/ads-api/
Eventually , one should use some client side code in order to get a user permissions and then make another request for getting the user token.
So you'll have to call
https://www.facebook.com/dialog/oauth?client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&scope=ads_management,offline_access&response_type=code
Get the authentication code and make another call:
https://graph.facebook.com/oauth/access_token?client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&client_secret=YOUR_APP_SECRET&code=AUTHORIZATION_CODE
Then you'll get an access token which is valid only for two months, in opposed to what Facebook docs says in here:
https://developers.facebook.com/roadmap/offline-access-removal/
"Ads APIs are special cased to allow collection of statistics offline. PMD partners should use server-side OAuth flow in order to receive a non-expiring token rather than a token that has longer expiration time."
Too bad that the access token is not really valid forever...
According to "Exception 4" in this document , if you have Ads API access you should be able to get a non-expiring token if you use the correct workflow. Following the guidelines outlined here, if you use the server side OAuth flow, to make the following request you should get a non-expiring token:
GET /oauth/access_token?
grant_type=fb_exchange_token&
client_id={app-id}&
client_secret={app-secret}&
fb_exchange_token={short-lived-token}
thx for the feedback regarding the Access token process being cumbersome. Because this is a one to many solution - a single App ID can manage multiple ad accounts, on behalf of multiple people - we need to make calls on behalf of people.
You should be able to get a persistent access token for Ads API. If you are not getting it, please provide exact steps you are following so we can see if there is a bug or you might be missing a step.
Thx.
Facebook has two flows for Authentication, client-side and server-side. When should each one be used?
Facebook docs: https://developers.facebook.com/docs/authentication/
Possibly related: What is the purpose of the implicit grant authorization type in OAuth 2?
Depending on your needs you can use one or the other or both. If you want calls to facebook to be processed before the user sees a certain page then use server side... however if you want to display partial information until the user has authenticated, use javascript authentication.
It boils down to this:
Javascript authentication can happen with-in a popup window and does not require a page reload you can also just perform a top.location.href redirect.
PHP authentication involves a redirect to an authentication page.
Also see this thread, in particular this response.
To add to #Lix's answer, I would say:
Client Side Authentication
When you want some information from Facebook API about the user that is required once, as in you only need to get it once like the user's name and email.
When you want to temporarily access/manage the user's information/data and don't need to do it often.
You get a temporary token, which is valid only for a few hours and you need to get a new token to call the Facebook API again after it has expired (which requires the user has to grant permission again).
Server Side Authentication
You want to manage the user's data (on their behalf) after the user has left your website/app. Example, gathering the user's feed/timeline data on a regular basis.
When you want to access/manage the user's information/data in a recurring fashion untill the user hasn't revoked access to your client id (represented by a Facebook app).
You get both a temporary token and a permanent token (which lasts for about 60 days at the time of writing this). You can get a new temporary token by using the permanent token every time you need to call the Facebook API (given the previous temporary token has expired) -- without bothering the user to grant permission again.
So, in short, for short term use, follow client-side authentication flow and for long term use follow server-side authentication (given you have a backend server of your own).
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.
I'm planning out adding Facebook integration to a web app I'm working on. For the most part, it's proceeding smoothly, but I am confused on the proper way to handle the OAuth token.
The sequence of events presented by Facebook here is:
Ask the user to authorize your application, which sends them to a Facebook window.
This will return an Authorization Code generated by Facebook
You then hit https://graph.facebook.com/oauth/access_token with your Authorization Code, which will give you a time-limited OAuth token.
Using the OAuth token, you can make requests to access the user's Facebook profile.
Facebook's documentation has the following to say about token expiration:
In addition to the access token (the access_token parameter), the response contains the number of seconds until the token expires (the expires parameter). Once the token expires, you will need to re-run the steps above to generate a new code and access_token, although if the user has already authorized your app, they will not be prompted to do so again. If your app needs an access token with an infinite expiry time (perhaps to take actions on the user's behalf after they are not using your app), you can request the offline_access permission.
When they say to re-run the steps above, what steps need to be re-run to get a new OAuth token? What data (Facebook UID, Authorization Code, OAuth token) does it make sense to save to my local database?
I would like to be able to have the user continue to interact with my site, and in response to certain user actions, I would like to be able to prompt to user if they want to post something to their Facebook wall.
The access token is time and session based and is unnecessary data to store and have no use after the user have closed the session.
The facebook uid is the only thing you need to identify the user.
Since the Facebook API sometimes is horrible slow you could store the username aswell.
But for identification, all you need is the uid.
The documentation that facebook provides has been updated since you asked this question. https://developers.facebook.com/docs/authentication/.