I have an app and a user who has added that app and authorized it with permissions: read_stream and user_status. I've got a node js app running that's trying to make an API call (using only the app credentials) to pull the user's posts but I get the following error:
"A user access token is required to request this resource."
How can this be done without having to have the user login every time I want to pull their feed?
It can't; you need a user access token to access that user's data - the error message is fairly clear about this I think.
Check the Authentication documentation - you should be storing the users' access tokens and using those to make API calls on behalf of those users
Related
Question: Is it possible for application which associated with business manager to obtain ads_management permissions and make server-to-server calls using appId|appSecret as access token.
If yes then what are the correct steps to obtain those permissions for an app?
If no then is there a way to get access token for the user with such permissions which never expires?
Details: As stated in FB documentation, in order to make server-to-server requests without need to obtain and refresh access tokens we may use pair of app Id and app secret in form of appId|appSecret.
Our application now has the following permissions:
- email
- public_profile
- user_friends
In order to make calls to Ads API our application has to have ads_management permissions. Currently we make calls to Ads API through user-level access token and this is not preferable for us as this token requires refreshes which must be done manually using browser interaction (we can't obtain access token programmatically)
You may be confusing App Access Tokens (which allow you to make calls on behalf of the app itself) with permissions (which an individual user grants you to act on their behalf) - you'll always need a user token to update things belonging to a user.
A user, who's an admin of the ad account you want to manage, needs to grant your app ads_management permission - once they've done that, the OAuth flow gives you an access token to make API calls on their behalf, and that token doesn't expire for up to 60 days (after which point they need to come back to your site/app while logged into Facebook for you to get an updated token)
In the context of Business Manager, that user must be someone that has access via Business Manager to the assets (ad acccounts and pages) you want to update via the API
If your app has Standard access to the Ads API, you can also use 'System Users' to make sessionless API calls to update the assets of the business: https://developers.facebook.com/docs/marketing-api/businessmanager/systemuser/v2.2
More info about login here:
https://developers.facebook.com/docs/marketing-api/guides/chapter-1-Setup-and-Authentication
https://developers.facebook.com/docs/facebook-login/access-tokens
Each user who allow permission to my app will have an access token
or
One access token can handle actions, for example, upload photos to an user album?
I know that an access token can expire up to 60 days,
so do I need save this access token for each user on my database and when request comes from that user, load the access token for him?
Each user who allow the app will have an access token, which will include all the permissions user has granted to your app.Read more about user access tokens here
Each user who allow permission to fb app, will have different Access Token which will be unique.
The Access Token is generated on the basis of browser session from client, AppID and App Secret. In a web server based application, it is not absolute requirement to save application token for user. But application like HootSuite saves user credentials and access token for later use to get facebook feeds and other services.
So it depends on application requirement.
Thanks
Each user sends you another access token in context to use User session of course.
An access token is a random string that provides temporary, secure
access to Facebook APIs.
A token identifies a User, App or Page session and provides
information about granted permissions.
And in User Access context:
You can use this token to perform API calls on behalf of a user,
including reading, publishing and deleting, depending on the
permissions your app has. For example, you can retrieve a user's
friend list or publish a new photo to their timeline with a user
access token.
http://developers.facebook.com/docs/concepts/login/access-tokens-and-types/
Yes, you have to remember this access token if you dont want to reconstruct it. But in many API's this is done "automagically", for e.x. in PHP SDK the access token is stored in user cookie. If you implement more complicated user-flow, you have to remember access token OR regenerate it each time (http://developers.facebook.com/docs/concepts/login/login-architecture/). Remember, that access token will expire and you will have to regenerate it (on the faith of already granted permissions).
FYI: If you want to preserver offline access (executing application activities without user session), you will consider offline_access, but it is deprecated:
http://developers.facebook.com/roadmap/offline-access-removal/
Hope it revealed the problem.
According to Facebook Devlopers: Test Users, I can list the test users of my facebook app by making a request to https://graph.facebook.com/APP_ID/accounts/test-users?access_token=APP_ACCESS_TOKEN. The response includes a valid user access token for each user.
How can I get a valid user access token for a specific test user without downloading the whole list of test users?
Test users should be able to be authenticated with your application in the same way as an other user. So use the Authentication flows while logged in for a specific test user.
Other than that there is no way to call one by one without parsing with code.
There is documentation for test users in the Facebook Developer online documentation but how do you delete actual users where the application doesn't show in their app list anymore? This is with the knowledge of the access_token and facebook_user_id.
Used to delete Test Users:
https://graph.facebook.com/893450345999?method=delete&access_token=A2ADI1YMySweBABBGrWPNwKMlubZA5ZCrQbxwhtlEd9FIQUrOVjsGD3mnIWEbUhzDz7dkuBekMFdHvjvJ9CZAU7EMSSaZBsgN60FkMCi3AAZDZD
Running the test user link produces the following error:
"error": {
"message": "(#100) Can only call this method on valid test users for your app",
"type": "OAuthException",
"code": 100
}
You seek for application de-authorization:
You can de-authorize an application or revoke a specific extended permissions on behalf of a user by issuing an HTTP DELETE request to PROFILE_ID/permissions with a user access_token for that app.
permission - The permission you wish to revoke. If you don't specify a permission then this will de-authorize the application completely.
To achieve this issue request to:
https://graph.facebook.com/me/permissions?method=delete&access_token=...
Once application de-authorized it will not appear in the list of user's applications.
Update December 2021
Follow the reference for Requesting & Revoking Permissions:
To remove single permission issue a DELETE request to /{user-id}/permissions/{permission-name} passing user access token or an app access token
To de-authorize an app completely issue similar request to the /{user-id}/permissions endpoint
Real users 'delete' themselves from your app when they remove your app from their account, you don't have to do anything.
If you would like to know when users de-authorize your app like this, you can specify a Deauthorize Callback URL in your app's settings. As described in the docs at https://developers.facebook.com/docs/authentication/:
Upon app removal we will send an HTTP POST request containing a single parameter, signed_request, which, once decoded, will yield a JSON object containing the user_id of the user who just deauthorized your app. You will not receive an user access token in this request and all existing user access tokens that were previously issued on behalf of that user will become invalid.
UPDATE: To remove your own app from the user's authorized applications, issue an HTTP DELETE to https://graph.facebook.com/[userid]/permissions?access_token=... as per https://developers.facebook.com/docs/reference/api/user/.
Typically Graph API calls also support doing an HTTP POST with an extra parameter, method=DELETE, in case DELETE calls are not possible/supported.
To do it:
You must have the user access token.
Visit https://developers.facebook.com/tools/debug/accesstoken/ and debug the user access token.
Copy App-Scoped User ID
Via API call HTTP DELETE to https://graph.facebook.com/[App-Scoped User ID]/permissions?method=delete&access_token=[YOUR-APP-ACCESS-TOKEN]
Facebook changed their Graph API recently to require an access token. Therefore I quickly made a Facebook application to be able to retrieve an access token, use a URL similar to the one below, generated my access token and implemented the token in my iPhone application. Lately I have been thinking about if I have done something wrong. Should I request the access token everytime a user of my application retrieves data from the Graph API? I am starting to doubt whether or not the access token is unique to each user or just to the Facebook application.
Can I hardcode an access token into my application or should I make a request on the URL below every time I need to retrieve data through the Graph API?
I am generating my access token with the following URL:
https://graph.facebook.com/oauth/access_token?client_id=MYID&client_secret=*MY_SECRET*&grant_type=client_credentials
Access token granted by user have expiration time. If token expired then you need to request it again. But if you ask user to grant you "offline_access" permissions then you'll have almost not limited access token. You can store it in database or file and use next time.
Here FB documentation about permissions:
http://developers.facebook.com/docs/authentication/permissions/
Enables your app to perform authorized
requests on behalf of the user at any
time. By default, most access tokens
expire after a short time period to
ensure applications only make requests
on behalf of the user when the are
actively using the application. This
permission makes the access token
returned by our OAuth endpoint
long-lived.