I'm crawlers that do a massive collections from Facebook pages and groups.
My main problem is that i get a lots of "Unsupported get request(100)" and " User request limit reached(17).
I'm using two kind of Tokens: Application-tokens and user-tokens (that i get from another service that connect to Facebook and get the token from the source of the page).
I need some ideas how to handle my Tokens, so i wan't reach this limit. I'm trying to switch to another token when i get the limit error, but since i have some services and each of them have some threads , it doesn't help.
Thanks for your help,
Related
On my site, I want to be able to retrieve whether my own YouTube account goes live. After looking around, I found this endpoint:
GET https://www.googleapis.com/youtube/v3/liveBroadcasts,
that would help me do just that. However, the main problem I found is that it requires an OAuth2 token, and the only way I could find to generate one was going through the whole Login with Google approach.
My main problem is that I want anyone who visits my site, to be able to see whether I'm live or not. I'm not looking for workarounds or using web crawlers either - I want to be able to use this specific endpoint. Is that even possible?
In other words, is it possible to get my own access token manually, and just plug that into the API request to access the endpoint directly? Or is this just impossible?
First thing to know about YouTube Data API is the following: for to issue authorized request to it, one cannot alleviate authentication through the browser.
You may read the doc OAuth 2.0 Flow: Installed apps for thorough info about the authorization flow on standalone computers.
The doc specifies step 4 -- Handle response from Google -- and step 5 -- Exchange authorization code for refresh and access tokens. By the initial OAuth flow, you get two tokens: a short-lived access token and a refresh token that produces access tokens on demand. Authentication without browser is not possible, but once having a refresh token, it can be traded programmatically for access tokens:
Initialization: obtain via browser authentication a refresh token;
Iterations: as many times as needed, query the API for an access token -- without any browser interaction! -- using the refresh token from (1), then proceed further with the call to the target API endpoint (again, without any browser interaction).
Note that the steps (1) and (2) may well be separated such that (1) is executed by a standalone (local) computer that stores the refresh token into a file; later, upon a secure transfer of that file on a different remote computer (e.g. a server that does not have a browser installed), execute (2) on that remote computer, repeatedly as needed
(see Using OAuth 2.0 for server-side, standalone scripts.)
Sounds right:
complete the flow (once) with your own google account,
cache the token server-side, and
include the API’s response when serving your page.
Pitfalls:
How long are OAuth tokens valid for? (The API will start returning errors if this occurs)
How often will the page be generated vs. what rate-limits does the API have? ( you may have to request status at most once per few minutes, and cache the response)
I am trying to collect visitor posts from the page of a political party. Even though I can collect the statuses posted from the political party itself, when I request a token for visitor_posts, I get the following error message:
{
"error": {
"code": 1,
"message": "Please reduce the amount of data you're asking for, then retry your request"
}
}
When I then add a limit, I get the same error message, even when I set the limit as 1, 10, or 100. After googling around, people then suggested to add a since/until, since there would be such a high number of visitor posts. However, when I tried that, it also did not work. Has Facebook changed its API to block this kind of collection?
Thanks in advance.
The endpoint [page]/visitor_posts is still functioning correctly, though there are prerequisites for calling it. Assuming you are a page management app, your access token must have manage_pages and pages_show_list scopes.
It isn't necessary for you to use a page access token to make this call and the request can be made with a user access token. It's also not necessary to have any permissions or specific roles on the page you are querying.
Since you are having issues with too much data being returned, although including a limit didn't help, you may help their query engine out by providing a since parameter. This is a filter for posts since a certain unix (seconds) timestamp, example using 12:00 AM UTC today:
[page]/visitor_posts?since=1523318400
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.
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.
As a proof of concept for a simple background application, I used the Graph API Explorer to create an access token for my app to post something to the wall of a page I maintain. It worked fine. Naturally, however, the token expires.
So now I'm trying to have the background application automatically request a new page access token each time it runs. And I'm having a lot of trouble finding a concrete definition of how to do that. There's no shortage of information regarding Facebook and Access Tokens, but nothing seems to demonstrate how to have a background application post to a page. (Not post to a user's wall, not display a login dialog to a user since it's a background application, etc.)
I can fetch an access token in code easily enough by reading the response from a web request to this URL:
https://graph.facebook.com/oauth/access_token?grant_type=client_credentials&client_id={MY_APP_ID}&client_secret={MY_APP_SECRET}
Of course, that "access token" doesn't work when trying to post to the page's wall. It says that the user hasn't authorized the application to perform this action. The action I'm performing is pretty simple:
var client = new FacebookClient(GetFacebookAccessToken());
dynamic parameters = new ExpandoObject();
parameters.message = "this is a test";
dynamic result = client.Post("{MY_PAGE_ID}/feed", parameters);
I've read in some places that I'll need to make a second request, using the first access token, to get the page access token. But I can't seem to find examples of how to do that.
Can someone shed some light on this for me?
I have a Facebook page.
I have a Facebook app which serves no other purpose than to provide a means for a local background application to access said page.
I just need that application to be able to authenticate so it can post something to the page.
(And if there's a step I need to perform in the Facebook UI to permanently give the application permission to do this, I think I've performed that step but it would be good to double check somehow.)
Edit: It's been described to me that I need to obtain a long-lived user access token and, using that, obtain a page access token. The theory is that said page access token won't expire. However, what's not clear to me is how one accomplishes this.
I've read the page describing the deprecation of offline_access, as well as the page describing server-side access. However, I'm clearly misunderstanding something. In the former, it references the latter for obtaining the proper token. The latter, however, includes steps for presenting a login to the user, having them accept permissions, and using the response from that login.
Being a background process that runs unattended, presenting any sort of question to a user (which would be me) isn't really an option. I've also been told that I can't do a one-time request from my browser to get an access token because that is, by definition, client-side interaction and not part of the necessary server-side flow. (It seems odd to me that the service would care if a RESTful request comes from a web browser vs. from an application, but I'm not familiar enough with OAuth or the Facebook API to really make that call.)
So, if I can perform some manual steps to get a permanent access token for the app to post to the Facebook page, what are those steps? Conversely, if I can perform some automated steps in the application to acquire access each time it runs, what are those steps?
(Making a few more API calls from the application adds a second or two of running time to an otherwise once-a-day process, so it makes no difference to me which approach to take.)
At first I just went into the Facebook Application settings and re-enabled the deprecated "offline access" permission. Said application settings can be found at a URL like this:
https://developers.facebook.com/apps/{APPLICATION_ID}/advanced
However, since everything keeps referring to that setting as being "deprecated" then I didn't want to use that as a long-term solution. It may get removed entirely, it may be unsafe in certain circumstances, etc. Better to use recommended functionality.
So here's what I was able to piece together from a scavenger hunt through updated documentation, outdated documentation, a sea of outdated internet posts, and PHP code which mostly made assumptions about functionality that aren't true in all cases...
Visit the Graph API Explorer and select your Facebook Application from the drop-down menu. Click "Get Access Token" and select the permissions you want. (For mine I went to the "Extended Permissions" tab and selected "Managed Pages" and "Publish Stream.") You will be prompted (in my browser it was in a new tab) with a familiar screen where the Facebook Application is asking you, the user, to grant it the permissions you just selected. (You've seen this before if you've ever agreed to use a Facebook Application before.)
The value it produces in the Graph API Explorer (a long string of random-ish characters) is your "Short Lived User Access Token."
As described here in "Scenario 4: Client-side OAuth and Extending Access_Token Expiration Time through New Endpoint" access this URL in your web browser:
https://graph.facebook.com/oauth/access_token?
client_id={APPLICATION_ID}
&client_secret={APPLICATION_SECRET}
&grant_type=fb_exchange_token
&fb_exchange_token={SHORT_LIVED_USER_ACCESS_TOKEN}
(You can obtain the {APPLICATION_SECRET} value on the basic settings page for your Facebook Application: https://developers.facebook.com/apps/{APPLICATION_ID}/summary)
This will return another Access Token as such:
access_token={LONG_LIVED_USER_ACCESS_TOKEN}&expires=5184000
This access_token value (another long string of random-ish characters) is your "Long Lived User Access Token." The expires value is in seconds, which translates into 60 days.
Now we hop over to the Page API reference and take a look at the section on Page Access Tokens. This, along with the basic structure of Graph API requests exemplified here (scroll down to the part where it shows a bulleted list of sample links which include access_token specifiers, which you'll need to specify here because you're requesting non-public information) leads you to request this in your browser:
https://graph.facebook.com/{FACEBOOK_USER_ID}/accounts?
access_token={LONG_LIVED_USER_ACCESS_TOKEN}
This will return a JavaScript object containing lots of useful information about the Facebook Pages and Facebook Applications your user account controls. In my case the Page and the Application had the same name, but it's easy to tell them apart from the category values or, if all else fails, the id values. Find the Page that the background application running on your machine will need to access and copy its access_token (the third and final long string of random-ish characters). The whole node looks something like this:
{
"name": "Some Facebook Application Name",
"access_token": "{LONG_LIVED_PAGE_ACCESS_TOKEN}",
"category": "Musician/band",
"id": "{APPLICATION_ID}",
"perms": [
"ADMINISTER",
"EDIT_PROFILE",
"CREATE_CONTENT",
"MODERATE_CONTENT",
"CREATE_ADS",
"BASIC_ADMIN"
]
}
This is your "Long Lived Page Access Token." This is the value you use to initialize the FacebookClient object in the code. Then, posting a simple status update is as easy as:
var client = new FacebookClient("{LONG_LIVED_PAGE_ACCESS_TOKEN}");
dynamic parameters = new ExpandoObject();
parameters.message = "This is a my status update.";
dynamic result = client.Post("{FACEBOOK_PAGE_ID}/feed", parameters);
Supposedly this "Long Lived Page Access Token" does not expire after 60 days like the "Long Lived User Access Token" does. I'll find out in 59 days, I guess.
NB: The curly braces in my examples are part of the placeholder for actual values. Do not use the curly braces in the actual requests. So something like this:
https://developers.facebook.com/apps/{APPLICATION_ID}/advanced
becomes something like this, for example:
https://developers.facebook.com/apps/123456/advanced
where 123456 is the actual Facebook Application ID.
Being a background process that runs unattended, presenting any sort of question to a user (which would be me) isn't really an option.
As I already said, you only have to do it once.
You get your non-expiring page access token, copy&paste that into your app – and from then on your app can do server-side whatever it wants to do happily everafter.
I've also been told that I can't do a one-time request from my browser to get an access token because that is, by definition, client-side interaction and not part of the necessary server-side flow.
The server-side auth flow for getting a user access token also needs to take part partly in the browser.
It does not matter, if you get a short-lived token via the client-side auth flow and extend it afterwards, or if you get a long-lived one using the server-side auth flow.
(It seems odd to me that the service would care if a RESTful request comes from a web browser vs. from an application […])
Facebook does not want users to give their login credentials to any third party. Therefor, the process of getting a user access token always has to take part in the browser, with the user login in to Facebook.
So, if I can perform some manual steps to get a permanent access token for the app to post to the Facebook page, what are those steps?
Get a long-lived user access token with manage_pages permission. (Or get a short-lived one, and extend it). And then, use that long-lived token to request a page access token for the target page, in the way that is described in the docs.